23 апреля 2018 года Mikrotik исправил уязвимость в RouterOS и Winbox, «которая позволяла получить доступ к незащищенному маршрутизатору». Была попытка выяснить, что именно было исправлено, в чем была проблема в первую очередь и насколько серьезным было ее влияние.

Для уязвимости в Winbox назначен номер CVE-2018-14847

Описание уязвимости: в MikroTik RouterOS до версии 6.42 включительно подключение с помощью Winbox позволяет удаленным злоумышленникам обходить аутентификацию и читать произвольные файлы, подменяя запрос на изменение одного байта, связанного с идентификатором сеанса.

История компании MikroTik

Согласно официальному сайту, MikroTik является латвийской компанией, которая была основана в 1996 году для разработки маршрутизаторов и беспроводных интернет-систем. В настоящее время компания предоставляет аппаратное и программное обеспечение для подключения к Интернету для большинства стран мира.

RouterOS — это основная операционная система большинства устройств Mikrotik. Уязвимость затрагивает все версии RouterOS от 6.29 (дата выпуска: 2015/28/05) до 6.42 (дата выхода 2018/04/20)

Также компания работает на операционной системой SwOS — это система, разработанная специально для управления коммутационными продуктами MikroTik.

SwOS настраивается из вашего веб-браузера. Он предоставляет вам все основные функции управляемого коммутатора, а также больше: позволяет управлять переадресацией между портами, контролем широковещательных запросов, применять фильтр по MAC-адресам, настраивать VLAN, зеркалировать трафик, применять ограничение полосы пропускания и даже настраивать некоторые поля MAC и IP-заголовков

Поиск различий в коде

Во-первых, мы должны были увидеть, какие бинарные файлы были изменены до и после исправления. RouterOS написан поверх ядра Linux, поэтому в каждой версии будет много разных модулей ядра. Мы загрузили npk файлы RouterOS 6.40.7 и 6.40.8 и для поиска различий сравнили файлы. Чтобы увидеть разницу, пришлось вычислять хеш суммы для большого набора файлов. Для нескольких из них сумма не совпадала. Как вы можете видеть, бинарный файл mproxy изменился. mproxy binary обрабатывает все запросы Winbox.

Поиск различий в коде mproxy

Разбираемся с “mproxy”

mproxy представляет собой двоичный код размером 63 Kилобайта без (за исключением простой секции NX) измерений безопасности. Так что эта ошибка могла быть связана с памятью. Запускали bindiff в файлах и находили некоторые различия между двумя версиями, но был простой условный оператор «if», который был добавлен в файл.

  Как подобрать коммутатор (Switch) для сети компании?

Изменение в схеме работы

Разблокировка устройства и отладка кода

Итак, как мы можем это проверить? У нас нет GNU Debugger (переносимый отладчик проекта GNU, который работает на многих UNIX-подобных системах и умеет производить отладку многих языков программирования), и у нас нет оболочки (пока). После некоторых поисков мы нашли интересный проект «mikrotik-tools». С его помощью мы сможем запустить оболочку bash внутри RouterOS и скопировать дополнительные двоичные файлы в свою файловую систему. Поэтому для выполнения этой работы мы добавили новый BusyBox в дополнение к gdbserver. Все, что вам нужно сделать, это смонтировать в виртуальной машине vmdk файл с RouterOS и добавить дополнительные файлы. После этого RouterOS загрузится и войдет в систему с учетной записью «devel» с тем же паролем, что и ваша учетная запись администратора. В этом сеансе telnet нет оболочки RouterOS, вместо этого будет загружен bash.

После установки точки останова в строке «list» мы начали копаться и, наконец, получили строку, которая обходит первое условие без нарушения каких-либо правил. Код сканирует строки по 4 байта за раз. Мы можем поместить наши точки останова между блоками по 4 байта, чтобы не  быть обнаружеными отладчиком.

Отправка пакетов

Начнем с отправки нескольких пакетов. Во-первых, мы можем и отключаем безопасную связь между роутером и Winbox. Посмотрев на пакеты, мы увидим крошечный файл обмена между маршрутизатором и Winbox, а затем мы увидим, что в Winbox отправляется список с файлами. Этот файл содержит все необходимые DLL-файлы для связи Winbox с маршрутизатором Mikrotik. Интересно, что этот подход имел более чем пару недостатков безопасности. Подумайте об этом, вы загрузите неизвестную DLL с удаленного хоста и запустите ее под с правами исполняемого файла Winbox. Прямо сейчас, мы хотим отключить этот список с помощью нашей созданной строки. Вот часть перехваченного обмена данными:

Проверка списка файла

Так что же такого интересного в этом перехвате? Если вы посмотрите внимательно, то увидите, что выделенные участки не являются первыми в обмене. Вначале Winbox выполняет аутентификацию на маршрутизаторе, а затем пытается получить файл списка. Довольно безопасно, не так ли? Мы тоже так думали, тем более, что мы повторяли отправку одних и те же пакетов и получили ошибку «неудачный идентификатор сеанса» от RouterOS. Но мы заметили что-то интересное. Один байт меняется каждый раз, когда мы отправляем один и тот же запрос на маршрутизатор, и каждый раз мы отправляем этот точный байт на маршрутизатор в нашем следующем запросе. Идентификатор сеанса? ДА! Таким образом, мы сделали повторную атаку с этой крошечной модификацией. Мы отправили запрос, дождались ответа маршрутизатора, переключили этот байт на байт, полученный от ответа, а затем отправили второй запрос и Voilà! Мы получили нужный нам файл! Нам даже не нужно было аутентифицироваться! Просто отправив пакеты в правильном порядке и переключив байт, маршрутизатор пропускает проверку подлинности.

  Правильный выбор Wi-Fi роутера

Общее правило построения систем проверки подлинности клиентов: не доверяйте клиенту Winbox проверку подлинности. Проверяйте корректность аутентификации на серверной стороне, на стороне RouterOS.

Расшифровка базы пользователей

Теперь мы можем прочитать ЛЮБОЙ файл с роутера! Какие файлы наиболее важные? Mikrotik использует очень слабую кодировку (без хеша и соли) для хранения паролей пользователей в индексном файле. Таким образом, вполне возможно загрузить базу учетных данных и извлечь все имена пользователей и паролей, хранящиеся в памяти устройства.

После загрузки idx-файла мы использовали еще один отличный инструмент из набора mikrotik-tools для дешифрования базы данных c именами пользователей и паролей и сохранения всех пар в виде открытого текста (plain text).

Какие выводы мы можем сделать?

На первый взгляд уязвимости подобного рода однозначно говорят нам: не используйте Mikrotik в корпоративной среде. Он не только ставит под угрозу безопасность организации, но и компьютер ИТ-персонала находится в рискованном положении. Существует возможность запуска и выполнения широкого спектра внешних DLL-библиотек под правами запущенного winbox.exe (для получения дополнительной информации введите в поисковой системе запрос по словам “ПО Slingshot”). Помимо всего этого, Mikrotik сохраняет ваши пароли в легко дешифруемом виде, что может повлиять на всю вашу сетевую инфраструктуру. Например, кодовые фразы SNMP обычно используются для нескольких сетевых устройств, включая маршрутизатор Mikrotik. Поэтому, если злоумышленник получает вашу кодовую фразу SNMP, то появляется возможность запуска атак на устройства Cisco, Juniper и более безопасные устройства 2 и 3 уровня. Как говорится: «Цепь сильна настолько, насколько сильно ее самое слабое звено». Но давайте посмотрим как на вызов отреагировала компания.

Компания отреагировала на уязвимость в Winbox

Благодаря данной уязвимости Mikrotik начиная с версии 6.43 внесла огромные изменения в свою политику безопасности маршрутизаторов:

  • пароли не будут более храниться в открытов виде, они будут кодироваться не обратимым образом
  • winbox, api и все логины соответственно изменены – больше нет возможности / ответа (ранее выглядело довольно странным возможность использования API TLS без проверки подлинности)
  • автоматическое обновление программного обеспечения сетевых устройств
  • и многие другие изменения, связанные с безопасностью
  Настройка OSPF Single Area на MikroTik

К сожалению, из-за этих изменений некоторые утилиты с открытым исходным кодом, такие как mac-telnet, больше не смогут работать как раньше.

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

Настройка MikroTik — базовые принципы защиты периметра

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

Кроме того, компания Mikrotik довольно оперативно отреагировала на уязвимость. Хотя мы знаем, что такие мастодонты телекоммуникационного рынка, как Cisco, Juniper и другие, часто очень долго исправляют свои уязвимости, если случайно не «забывают» их исправить.

Что же касается уязвимости Winbox, то выполнение сторонней DLL является большим риском для корпоративной среды (хотя разработчики и стали подписывать приложение своим сертификатом для подтверждения легитимности исполняемого файла). Скажет Winbox не является обязательным для повседневного использования инструментом, существует множество других способов управления устройствами Mikrotik:

Заключение

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

Читать далее

Раскрытие критической уязвимости в Winbox CVE-2018-14847
Метки:            
Adblock detector