Все новое – это хорошо забытое старое (а еще лучше очень хорошо забытое старое).
Конечно, следить за новыми уязвимостями правильно, но и о старых забывать не стоит. Особенно когда производитель позволяет себе о них «забыть».
Кто-то должен помнить.
В противном случае мы снова и снова будем наступать на одни и те же грабли.
В статье речь пойдет об одной старой, но, как оказалось, не потерявшей актуальности и по сей день, дыре UPnP. 
P.S. Провайдера называть не буду, это не его вина, но с другой стороны, налицо явный недосмотр политик безопасности, который в совокупности с архитектурой сети позволил эксплуатировать эту уязвимость.
Как это всегда бывает, звезды сошлись.
Провайдер установил в своей сети роутеры для клиентов с необходимыми чипами и связал их внешним IP-адресом.
Да, большая часть портов отфильтровалась, но почему-то не 52869. П.
П.
С.
Все события произошли в конце 2018 года.
Персонажи вымышленные, а любые сходства с реальными людьми случайны.
Краткая образовательная программа: Существует некоторая библиотека разработки libupnp, которая «используется на тысячах устройств и называется Intel SDK для устройств UPnP или Portable SDK для устройств UPnP».
По-английски:
«Портативный SDK для устройств UPnP (libupnp) предоставляет разработчикам API и открытый исходный код для создания точек управления, устройств и мостов, которые соответствуют версии 1.0 спецификации архитектуры устройств Universal Plug and Play и поддерживают несколько операционных систем, таких как Linux. , *BSD, Solaris и другие».Первое упоминание об уязвимости было еще в 2014 году: тыкать Попытки связаться с производителем не увенчались успехом, и уязвимость была опубликована.
Единственная рекомендация по противодействию заключалась в следующем:
«.В службе miniigd SOAP существует ошибка.ограничение взаимодействия с сервисом.
С ним должны иметь возможность общаться только клиенты и серверы, имеющие юридические процессуальные отношения.
».
Проблема в обработке запросов NewInternalClient из-за невозможности очистить пользовательские данные перед выполнением системного вызова.
Злоумышленник может воспользоваться этой уязвимостью для выполнения кода с правами root. Те.
Все маршрутизаторы, на которых работает UPnP 1.0, могут выполнять произвольный удаленный код. Без авторизации.
От корня.
Отлично, правда? Любой желающий может найти на github готовый плагин для метасплоита, работоспособность которого проверена на сгоревших стульях наших дежурных инженеров.
Это было неожиданно и совсем не весело.
Краткая хронология событий того дня:
14:00 В техподдержку начинают поступать обращения от абонентов по поводу плохо работающего Интернета.
- Симптомы со стороны клиента: «работает медленно, после перезагрузки какое-то время работает нормально, потом снова медленно работает».
- Симптомы со стороны железа: небольшой всплеск трафика и нагрузка на процессор были связаны с нагрузкой, создаваемой самим клиентом.
Общего шаблона действий не существует. Ничего не могу понять.
15:00 Количество заявок начинает превышать среднюю температуру по больнице и одиночные заявки начинают формироваться в большее количество заявок с типом «Несчастный случай».
Запросы передаются старшим администраторам для проверки сегментов сети.
15:20 Админы закрывают массовые аварии, потому что.
Проблем в сети нет, все запросы клиентов идут из разных точек подключения и одиночные.
(например: свитч переполнен активными абонентами, но у одного работает плохо).
В этот момент призывы стихают и все успокаивается.
Кто-то замечает (наконец-то), что все приложения по плохой работе были с одной и той же моделью роутера, все в один голос делают вид, что все хорошо.
15:30 Опять наплыв заявок от подписчиков, опять регистрируется и передается администраторам массовая авария.
В этот момент становится ясно, что что-то Действительно это не правильно и надо что-то делать (кто работал с клиентской службой поймет, как это иногда сложно сделать.
Клиенты всегда врут, а иногда первая линия лежит, чтобы еще больше нагнетать задачу).
15:35 Дежурный инженер получает запрос на проблему со службой поддержки клиентов.
Получает список всех клиентов, их тип подключения и модель устройства.
И тут начинается немного волшебства.
спойлер Что, кстати, не сработало и главного мага потом уволили (но говорят, не за это).
15:40 Инженер прогоняет список клиентов по всей доступной диагностике, каждый роутер проверен по всем стандартным метрикам и.
ничего не найдено.
Роутер как роутер.
Да, ЦП увеличился, но показатели не критичны, но трафик куда-то отправляет, значит работает. Да, служба UPnP работает на порту 52869. Да, там еще куча открытых портов, открытые значит они нужны (железная логика), и он всегда туда обращался и проблем не было (еще один аргумент железной логики).
Прямой ssh к этой модели роутера невозможен (честно говоря, возможен, но внутри сильно урезанный busybox и политика компании не сильно поощряла такой трафик на клиентских устройствах).
Все возвращается в норму.
16:00 Только сейчас мы узнаем, что есть некоторые проблемы.
Дежурный инженер отчитывается перед своим менеджером, а менеджер звонит нам, сообщает нам свои предположения о порте 52869 и просит о помощи.
16:05 Дальше все произошло очень быстро.
К стенду подключается роутер той же модели, IP-адрес берется у проблемного клиента и присваивается стенду.
Вайршарк включен.
Это для перехвата запросов к устройству.
Для перехвата запросов от роутера (общая схема взаимодействия на тот момент была еще неизвестна) клиент изолируется в тестовом сегменте и весь его трафик зеркалируется на ближайшую тестовую машину, где работает другой Wireshark. Потом ждем, смотрим на экран.
Взломы таким образом они уже ловили – довольно эффективно, а потому решили не менять своих привычек.
16:10 Пока Wireshark шуршит, Google обнаружил уязвимость CVE-2014-8361, о которой сообщает инженерам.
Инженер, не дослушав до конца, принимает решение (и в принципе логичное) - фильтр для этого порта на границах.
Сказано - сделано.
спойлер Это не сработало.
16:25 Нам говорят, что Миша переделал всю эту фигню, не получилось.
И мы уже знали, что это не сработает. К тому времени уже постучали по тестовому роутеру, подняли реверс и поехали в друг порт и начал использовать его параллельно для DDOS через порт 1900(!), используя другую уязвимость.
Боже, какое дырявое мусорное ведро! еще одна образовательная программа Использование в DDoS-атаках схематический В 2014 году неожиданно было обнаружено, что SSDP использовался в DDoS-атаках, таких как «атака отражения SSDP с усилением».
Многие устройства, в том числе домашние маршрутизаторы, имели ошибку в программном обеспечении UPnP, которая позволяла злоумышленнику пересылать ответы с порта 1900 на произвольный адрес в Интернете.
В случае ботнета, состоящего из многих тысяч однотипных устройств, злоумышленник может создать большой поток пакетов, достаточный для того, чтобы занять полосу пропускания и насытить каналы передачи данных атакуемого сайта, что приводит к отказу в обслуживании обычных пользователей.
.
Самое интересное, что правила фаервола на устройстве были изменены и nmap больше не показывал открытые порты с внешнего устройства.
Только в дампе трафика можно было обнаружить запросы на эти порты.
Те.
После взлома злоумышленник заблокировал доступ другим лицам.
Не высокотехнологичный подход, но все же - браво.
16:30 Проводится конференция с вопросами «кто виноват и что делать».
Они покинули порты 1900 и 52869 под запретом.
Предпринимаются попытки что-то исправить на взломанных устройствах.
Перезагрузка не помогла, идея перепрошить была сразу отвергнута.
Да, такой функционал доступен; можно было переставлять ПО на всех устройствах удаленно через TR069 одной кнопкой.
Но т.к.
устройство было не самое новое, а количество клиентов было большим - определенный процент поврежденных устройств создавал бы проблемы.
16:40 Подведем краткий итог: устройства взломаны, участвуют как минимум в DDoS и что-то куда-то передают по зашифрованному каналу.
(Все на другой порты).
Попасть внутрь невозможно; вендор запретил полный доступ по ssh к устройству и невозможно посмотреть, что именно там напортачили.
Консоль защищена паролем.
Где-то ближе к 17:00 Было решено прошить аппараты как самый быстрый способ.
После перепрошивки и перезагрузки все вернулось на круги своя.
Вместо результатов
К сожалению, нам не удалось полностью решить эту проблему.Под «решением» я подразумеваю получение полной картины нарушения и обновление наших политик, чтобы предотвратить его повторение в будущем.
Да, не все поставленные задачи решаются успешно и так, как хотелось бы.
Это отлично.
Даже если это обидно.
Если вы хорошо ищете на Shodan, тогда ты сможешь найти что-то для себя для экспериментов: Так или Так но я тебе этого не говорил.
Теги: #информационная безопасность #сетевое оборудование #Realtek #бэкдор
-
Проверено Обучение Microsoft Mcsa
19 Oct, 24 -
Горячие Клавиши
19 Oct, 24 -
Мозговой Штурм – Название Ip Атс
19 Oct, 24 -
Отражён Браузерозависимый Xss На Mts.ru
19 Oct, 24 -
Новое В Haiku (Svn)
19 Oct, 24
