Пользователь
0,0
рейтинг
17 мая 2013 в 15:28

Проблемы безопасности в сетевых устройствах 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</code>


К сожалению, данный файл также только для чтения, а исполняемые файлы, отвечающие за работу железа, не выдают подсказок, поэтому на этом работу с 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 было представителями компании проигнорировано. Несмотря на это, никакого предубеждения против продукции компании я не испытываю — по соотношению цена/функционал устройство вполне конкурентоспособно. Неприятно просто как-то, болезни роста, что-ли.
@random1st
карма
3,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (2)

  • +1
    Недавно начал работать с оборудованием ZTE — софт глючный до невозможности. Единственное, что более-менее нормально работает — L2 switching.
    Пару примеров, вот буквально из последнего:
    1) High-end роутер серии 89xx не осилил обработку фул вью, причём умирал по cpu. После этого стала сыпать ошибками линейная карта, помог только ребут.
    2) Роутер линейки чуть пониже не осилил даже 10к префиксов.
    3) Туда же мультикаст роутинг — запрос всего одной-двух групп внезапно может загрузить 100% cpu.
    4) А ещё они не понимают AD, хотя команды соответствующие есть.
    А как свитчи — вполне ок, дёшевые и работают довольно надёжно.
  • 0
    Раз уж пошла тема про безопасность, мне понравился случай с huawei на роутере AR1220. По документации уровень 1: monitoring не может сохранять конфигурацию. Ну и перезапускать роутер не может. На деле оказалось почем-то что команда reboot имеет уровень доступа на 3, а 1. При чем перед перезагрузкой роутер спрашивает, сохранять ли конфигурацию и сохраняет ее. В результате пользователь с уровнем monitoring может и перезагрузить роутер и сохранить конфигурацию) Прелестно) Решается это несложно, ручным изменением уровня доступа, но ситуация меня очень удивила)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.