Проблемы безопасности в сетевых устройствах ZTE

Вступление

Начну, пожалуй, с небольшой предыстории. Мое знакомство с сетевыми устройствами китайских компаний датируется 2006 годом, когда, работая на одного из операторов мобильной связи, я познакомился с маршрутизаторами компании Huawei. Должен сказать, что в том зоопарке наглядно прослеживалась вся история становления — от первой линейки с нумерацией, аналогичной Cisco, повторяющая синтаксис команд и даже использующая фирменные протоколы маршрутизации Cisco и кучей косяков в довеску до весьма «красивой» и сравнительно надежной техники со своим синтаксисом и особенностями реализации. Собственно говоря, я и сейчас в основном работаю с оборудованием этой фирмы. Не стоит думать, что я считаю намного хуже оборудование компании ZTE, однако программная начинка абонентских устройств меня весьма удивляет, не меньше, чем запись команды «show run» в startup-config на первых маршрутизаторах Huawei.

Знакомство

Объектом моего исследования выступил мой домашний шлюз ZTE H208L, сочетающий функции ADSL-модема, маршрутизатора, WiFi точки доступа, клиента SIP телефонии с FXS-портом.

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

В круге первом: telnet

Устройство стандартно отвечает на порту 23, запрашивая логин/пароль (root/root), не пишу по умолчанию, ниже поймете, почему.Попадаем в shell:

BusyBox v1.01 (2012.03.06-03:19+0000) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

# cat /proc/cpuinfo
system type: Amazon-S
processor: 0
cpu model: MIPS 34K V4.12
BogoMIPS: 222.00
wait instruction: yes
microsecond timers: yes
tlb_entries: 16
extra interrupt vector: yes
hardware watchpoint: yes
ASEs implemented: mips16 dsp mt
VCED exceptions: not available
VCEI exceptions: not available
# mount
/dev/mtdblock6 on / type squashfs (ro)
/proc on /proc type proc (rw)
tmpfs on /var type tmpfs (rw)
tmpfs on /mnt type tmpfs (rw)

Итак, видим, что через telnet монтирован корневой раздел только для чтения. Соответственно, файл /etc/passwd смонтирован только для чтения, поэтому поменять пароль просто командой passwd мы не можем. Опять же забегая вперед, могу сказать, что эту настройку мне удалось изменить прямым редактированием конфига. Покопавшись в поисковике, выяснил, что через telnet тремя командами можно активировать скрытые страницы настроек, в частности, настройки SIP и некоторые другие. Меня заинтересовало другое — есть ли возможность получить какие-либо данные о настроенных аккаунтах. После недолгих поисков обнаружил файл /var/tmp/version-cfg, хранящий все возможные данные в открытом XML-подобном виде.

Фрагмент файла конфигурации

</Row> </Tbl> <Tbl name="TelnetCfg" RowCount="1"> <Row No="0"> <DM name="TS_Enable" val="1"/> <DM name="Wan_Enable" val="0"/> <DM name="Lan_Enable" val="0"/> <DM name="TS_Port" val="23"/> <DM name="TS_UName" val="root"/> <DM name="TS_UPwd" val="root"/> <DM name="Max_Con_Num" val="5"/> <DM name="ProcType" val="0"/> </Row> </Tbl> <Tbl name="RouteSYSRT" RowCount="1"> <Row No="0"> <DM name="Display" val="0"/> </Row> </Tbl> <Tbl name="L2BBridge" RowCount

К сожалению, данный файл также только для чтения, а исполняемые файлы, отвечающие за работу железа, не выдают подсказок, поэтому на этом работу с telnet-интерфейсом завершаем.

В круге втором:Web-интерфейс

По 404 ошибке выясняем, что дело мы имеем с Mini web server 1.0 ZTE corp 2005. Вот такой милый зеленый интерфейс мы получаем после POST-аутентификации (логин и пароль по умолчанию admin/admin)

Ага, выгрузив файл конфига и вручную поправив в нем пароль telnet, я успокоился. Ненадолго.

Задачу перед собой я поставил простую — автоматизировать процесс выгрузки, загрузки и правки конфига. Вооружившись Fiddler’ом, я отсниффил HTTP-запросы, гуляющие в процессе пользования интерфейсом и выяснил, что после отправки данных формы авторизации мне нужно отправить POST-запрос multipart/form-data по адресу /getpage.gch?pid=100. И тут в процессе отладки обнаружил, что для загрузки конфига
мне не нужно авторизовываться. Повнимательнее пересмотрев историю запросов, обнаружил, что и без авторизации зайдя на адрес 192.168.1.1/manager_dev_config_t.gch получил такую страничку:

Кнопка Backup работала, Restore нет. Я все же решил пойти до конца, и в итоге получил пару скриптов (VBScript для windows) в качестве параметра оба принимают адрес модема. Кода полностью здесь приводить не буду, дабы не плодить малолетних куллхацкеров, это всего лишь эмуляция HTTP запросов, вот главная часть
Set HTTP = CreateObject("Msxml2.XMLHTTP.6.0") Set ArgObj = WScript.Arguments URL=ArgObj(0) BOUNDARY="------12345678" HTTP.open "POST", "http://"&URL&"/getpage.gch?pid=100" parameters=BOUNDARY&vbCrLf&"Content-Disposition: form-data; name="&Chr(34)&"config"&Chr(34)&vbCrLf&vbCrLf&"--"&BOUNDARY&"--"&vbCrLf HTTP.setRequestHeader "Content-Type", "multipart/form-data; boundary="&BOUNDARY HTTP.setRequestHeader "Content-Length", Len(parameters) HTTP.send( parameters ) .

Выводы

Являются выявленные проблемы критичными? Сомневаюсь, в конце концов, это домашний шлюз, и с корректными настройками WiFi его не поломаешь таким образом. Но вот в применении в сетях организаций, учитывая, что уязвимость затрагивает и часть других устройств, в частности, PON терминалы (правда, там конфиг уже не plain-text) без дополнительных костылей мне представляется сомнительным. Мое обращение в техподдержку ZTE было представителями компании проигнорировано. Несмотря на это, никакого предубеждения против продукции компании я не испытываю — по соотношению цена/функционал устройство вполне конкурентоспособно. Неприятно просто как-то, болезни роста, что-ли.