Патчи для DIR-645 и DIR-890L одинаковые, поэтому я буду писать только про DIR-890L.
Хоть в предыдущем посте я рассматривал только выполнение команд, патч указывает на несколько дыр в безопасности, которые появились из-за использования
strstr для валидации HNAP-заголовка SOAPAction:- Использование неаутентифицированных пользовательских данных в вызове
system - Использование неаутентифицированных пользовательских данных в вызове
sprintf - Неаутентифицированные пользователи могут выполнять привилегированные HNAP-запросы (такие, как смена пароля администратора)
Видите, D-Link признала все это в информации об уязвимости, и они ясно представляли все векторы атаки.
Итак, убрали ли они переполнение стека
sprintf?
sprintf(cmd_buf, “sh %s%s.sh > /dev/console”, “/var/run”, SOAPAction);
Нет.
Убрали ли они вызов
system?
system(cmd_buf);
Конечно нет!
Используют ли они
strcmp вместо strstr для валидации заголовка SOAPAction?
if(strstr(SOAPAction, “http://purenetworks.com/HNAP1/GetDeviceSettings”) != NULL)
Пфф, че заморачиваться-то?
Все их решение этих фундаментальных проблем сводится к использованию функции
access для проверки того, что в SOAPAction допустимое, ожидаемое значение, путем проверки существования файла /etc/templates/hnap/<SOAPAction>.php:
Вызов sprintf(), затем сразу access()
Ага, это хотя бы защитит от внедрения произвольных данных в
sprintf и systemОднако, они добавили еще один
sprintf до access; их патч для закрытия неаутентифицированного переполнения стека в sprintf добавляет еще одно неаутентифицированное переполнение стека в sprintf.А вот еще один неожиданный поворот: этот патч не делает ничего для того, чтобы запретить выполнение допустимых административных запросов HNAP, т.к. он только проверяет, допустим ли запрос. Все верно, их патч не закрывает все уязвимости, о которых они писали в информации об уязвимости!
Думаю, никому нет дела до того, что любой неаутентифицированный пользователь может получить информацию о хостах во внутренней сети, просматривать и изменять системные настройки или сбросить роутер на заводские настройки:
$ wget --header="SOAPAction: http://purenetworks.com/HNAP1/GetDeviceSettings/SetFactoryDefault" http://192.168.0.1/HNAP1Оставайся таким же классным, D-Link.
UPD: D-Link выпустили обновление, закрывающее уязвимости
Комментарии (47)
Disasm
27.04.2015 22:32+12Надеюсь, хотя бы в OpenWRT такого нет.
maisvendoo
28.04.2015 11:15+4OpenWRT легко проверить, ибо код открыт. Кстати, хорошая тема для ребят, ведущих блог о PSV Studio
Disasm
28.04.2015 11:18Было бы кому проверять ещё. А PVS Studio вряд ли умеет искать закладки, подобные тем, что описаны в этой статье.
maisvendoo
28.04.2015 14:54Насколько я понял, уязвимости, описанные в статье возникают в том числе из-за небезопасного использования C-функций работы со строками. PVS Studio анализирует код на предмет таких проблем.
P.S.: Почитав такую информацию, прихожу к выводу, что покупая роутер лучше брать модель допускающую перешивку открытым ПО… Что собственно и делаюDisasm
28.04.2015 14:57Это да, но вызов функции system, в которую попадают данные от пользователя, он вряд ли найдёт. Тут уже taint-анализ нужен.
INSTE
28.04.2015 14:24+1А что там в OpenWRT проверять на PVS? Ядро там — ванильный Linux, морда на lua. Разве что UCI и procd.
BalinTomsk
28.04.2015 05:29-1---Используют ли они strcmp вместо strstr для валидации заголовка SOAPAction?
Как? Это перпедикулярные функции.
AxisPod
28.04.2015 06:13+2Не совсем конечно так, strcmp сравнивает строки, strstr ищет вхождение подстроки в строке. Но частично вы правы, функции не взаимозаменяемы.
robux
28.04.2015 11:11-9> Да какого, блин, хрена, D-Link?
Сомневаюсь, что они не могут закрыть описанные уязвимости.
Скорее всего — не хоят. Здесь правильно вспомнить Сноудена и то, о чём он говорил.
D-Link — тайваньская корпорация, а Тайвань, как и Япония с Южной Кореей, всеми костьми лежит под США.
Корпорациям так просто никто не позволит полностью закрыть все уязвимости.INSTE
28.04.2015 14:23+6Все проще — им просто плевать (бах-бах и в продакшн в кристаллизованном виде).
Китайцы пишут свои прошивки на «отвали»: запустилось и ладно.
Чего стоит ситуация с китайским DIR825B1 на Atheros, в котором в самой новой прошивке падает ядро на более-менее сильном upload на L2TP.
И самое главное — им почти бесполезно жаловаться и слать багрепорты: исправят только если придет приказ сверху, а просто так никто не будет работать.
pcdesign
28.04.2015 12:24+1А подскажите, пожалуйста, эта уязвимость реализуется только за натом из сети 192.168.х.х?
Или можно к белому IP адресу роутера подключиться и эксплуатировать данную уязвимость?
xBrowser
28.04.2015 13:06В первом посте было сказано:
Мы можем отправлять HNAP-запросы из WAN, если было включено удаленное администрирование.
Следовательно уязвима только минимальная часть устройств. Либо беспарольные/взломанныечерез Wi-Fi.
К слову, мне не удалось воспроизвести уязвимость через WAN, протестировав 2 сегмента сети. Не одного из 50 устройств, ответивших по 80/8080 порту.
umraf
28.04.2015 12:55+2Интересно, у кого-нибудь получилось воспроизвести уязвимость? На каких железках?
xBrowser
28.04.2015 13:16+1До вышеупомянутого патча были уязвимы:
Список устройств, подверженных рискуDAP-1522 revB
DAP-1650 revB
DIR-880L
DIR-865L
DIR-860L revA
DIR-860L revB
DIR-815 revB
DIR-300 revB
DIR-600 revB
DIR-645
TEW-751DR
TEW-733GRINSTE
28.04.2015 14:21Подвержены уязвимости только с китайской прошивкой — с русской нет. Например те же самые 815 / 300 русские этому не подвержены.
dcc0
28.04.2015 19:46Вспомнил, что собирал для 320 прошивку из исходников, был тулчейн и «руводство от Олега». Но там BCM5354.
А для DIR-890L есть что-то подобное?
powerman
28.04.2015 23:13Вообще-то пользователи, которые настолько беспокоятся о безопасности роутеров, что готовы следить за выходом новых версий и обновлять прошивки, обычно начинают с того, что ставят OpenWRT. Потому что всем, кому этот вопрос интересен, давно понятно, что безопасности от родных прошивок роутеров, хоть D-Link хоть кого другого, ждать наивно.
INSTE
29.04.2015 15:40И сразу получаем на порядок более низкие скорости маршрутизации, кое-как работающий WiFi (даже у atheros есть ограничения в открытых драйверах по multicast), низкие скорости работы с USB-накопителями, неработающие ускорители криптоопераций и многое другое.
Вы именно затем покупаете роутер, чтобы максимально не использовать все его фичи? :)powerman
29.04.2015 17:40+1FUD. У меня стоит OpenWRT на гигабитном роутере с WiFi, никаких проблем ни со скоростью маршрутизации, ни с WiFi нет. Насчёт USB не знаю, но крупно сомневаюсь что в линухе на роутерах есть какие-то проблемы с USB. Ускорение криптоопераций — запросто может и не работать, в это верю легко… только вот нафига мне быстрые криптооперации, если кто угодно может получить на этом роутере рута и снифать весь трафик и память хоть до хоть после этих невероятно быстрых криптоопераций?
INSTE
29.04.2015 18:39Проблемы есть, и очень большие — думаю сами знаете, как быстро работает ntfs-3g через fuse на обычных компах. А теперь можете представить как оно работает на мелких процах роутеров, которые «благодаря» переходу на OpenWRT вынуждены еще и программно маршрутизировать трафик.
Не утверждаю, что D-Link идеал по качеству и поддержке прошивок, скорее даже антипример, но советовать пользователям абсолютно всех роутеров сразу бездумно ставить OpenWRT без осознания ими что они потеряют при этом — очень глупо.maisvendoo
29.04.2015 23:20бездумно ставить OpenWRT без осознания ими что они потеряют при этом — очень глупо.
В моих руках побывало два роутера от TP-Link: 1043 nd v2 (мой) и 842 nd (брату подарил). Оба перепрошил достав из коробки (первый и покупался с целью перепрошивки «напосмотреть»). Чтобы что-то не работало — такого не было. Оба девайса прекрасно выполняют все свои функции.INSTE
30.04.2015 02:08Самые дешевые устройства на устаревших чипах Atheros не имеют аппаратных ускорителей, поэтому на них OpenWRT можно ставить безболезненно.
Ну и естественно — работать-то все будет. Вопрос в том насколько быстро и какие показатели производительности все это будет выдавать.maisvendoo
30.04.2015 08:57дешевые устройства на устаревших чипах Atheros не имеют аппаратных ускорителей, поэтому на них OpenWRT можно ставить безболезненно.
М-да, немного оффтоп, но вспоминается шутка одного из известных в недавнем прошлом видеоблогеров, на тему ответа на вопрос, что же лучше: родная прошивка, OpenWRT или самодельный роутер. Ответ — лучше… лучше Cisco!INSTE
30.04.2015 21:47Шутки шутками, а циска выдает задекларированные показатели именно благодаря аппаратному ускорению большого числа операций на ASIC. ОС там в основном для сохранения конфига, мониторинга и настройки/поддержания в нужном состоянии ASIC.
Но потому она и стоит дороже всех остальных «полупрограммных» и полностью программных решений.
INSTE
29.04.2015 18:49Ну и вот для примера только вчера измеренная скорость маршрутизирования на гигабитном DIR-825B1, прошитом в OpenWRT 14.07 (2 потока TCP, гигабитные каналы, сервер accel-ppp 1.7.4, mtu 1400: идеальный вариант с низким pps) (загрузка процессора при этом равна 100%, то есть даже веб-интерфейс не открывается):
IPoE: 220 мегабит/с
PPTP: 42 мегабит/с
L2TP: 140 мегабит/с
PPPoE: 180 мегабит/с
Если вы считаете, что для гигабитного роутера это нормальные скорости в «идеальных» (с точки зрения pps) условиях — то дальше не о чем говорить.powerman
29.04.2015 19:47У меня тоже DIR-825 B1. Инет у меня 100Mbps (и роутер их честно выдаёт), так что гигабит наружу потестировать возможности нет. А внутри локалки сейчас скопировал 5GB фильм с виндовой машины на линуховый сервер по самбе — 80MB/sec, т.е. порядка 650 мегабит/c минимум, и я абсолютно уверен что ограничивающим фактором была скорость винтов. Да, запустил сейчас копирование в /dev/null — в начале было 92-93MB/sec. Если прерывать копирование где-то на 20% и запускать с начала (чтобы винда закешировала начало файла и отдавала его из памяти) — я и 103MB/sec видел. По-моему это вполне честный гигабит. OpenWRT у меня правда давно не обновлялся, вроде версии 10.x.
INSTE
29.04.2015 20:28Не, то, что встроенный RTL8366S коммутирует пакеты на гигабите — это даже не обсуждается, все-таки это аппаратный свитч. И тут я согласен, что 110-120 Мбайт/сек получить вообще не проблема. Если бы уж и коммутация свичем была бы программной, то это было бы совсем вызывающим ужасом.
Я же писал про скорости WAN <-> LAN.powerman
29.04.2015 20:38Ну, формально у меня линух-сервер как раз в WAN порт подключен. Но я согласен, это не то же самое, что вышеупомянутые IPoE/PPTP/etc. А есть цифры, сколько они выдают на родной прошивке?
INSTE
30.04.2015 02:10Не помню, поскольку родная прошивка была снесена еще пару лет назад :)
Но думаю ситуация именно с NAT была бы примерно равной: этот чип не имеет модулей аппаратного ускорения (поэтому российский DLink с 2012 года на них ничего не делает). Другое дело MediaTek/Broadcom/Realtek.
maisvendoo
Можно оффтопный вопрос — какой отладчик изображен на скринах? А то, к стыду своему, не признаю этих окошек, но судя по шрифтам и именованию меток это встроенный в IDA Pro?
rrock
Это раскрытый элемент графа в IDA. Просто дизассемблер.
ValdikSS Автор
Это и есть IDA Pro, Graph View. Нажмите пробел или минус.
maisvendoo
Спасибо