Всё новое — это хорошо забытое старое (а лучше очень хорошо забытое старое). Следить за новыми уязвимостями, конечно же, правильно, но и о старых забывать не стоит. Тем более, когда о них позволяет себе «забыть» производитель. Кто-то должен помнить. Иначе мы снова и снова будем наступать на одни и те же грабли.
Речь в статье пойдет об одной старенькой, но, как оказалось, ни разу не потерявшей актуальности и по сей день, дыре UPnP.
P.S. Провайдера называть не буду, вины его в этом нет, но с другой стороны есть явный недосмотр политик безопасности, которые вкупе с архитектурой сети дали возможность проэксплуатировать эту уязвимость. Как это всегда бывает — звезды сошлись. Провайдер ставил на своей сети роутеры клиентам с нужными чипами и подключал с внешним ip адресом. Да, большинство портов были зафильтрованы, но почему-то не 52869.
P.P.S. Все события произошли в конце 2018 года. Герои вымышлены, а совпадения с реальными личностями случайны.
Первое упоминание об уязвимости было в далеком 2014 году: тык
Попытки связаться с производителем особого успеха не принесли и уязвимость была опубликована. Единственной рекомендацией по противодействию было:
Т.е. на всех роутерах с версией UPnP 1.0 можно выполнять произвольный удаленный код.
Без авторизации. От рута. Здорово, правда?
Любой желающий может на github'е найти готовый плагин для метасплоита, работоспособность которого проверена прожженными стульями наших дежурных инженеров.
Было неожиданно и совсем не весело.
14:00 В техническую поддержку начинают поступать обращение абонентов на плохо работающий интернет.
Регистрируются одиночные заявки для проверки линии на админов, либо на выезд монтажника. Никакого общего шаблона для действий нет. Ничего не понятно.
15:00 Количество заявок начинает превышать среднюю температуру по больнице и одиночные заявки начинают лепить в заявки по больше с типом «Авария». Заявки передаются на старших администраторов для проверки сегментов сети.
15:20 Админы закрывают массовые аварии, т.к. проблем на сети нет, все заявки клиентов с разных точек подключения и одиночные. (к примеру: коммутатор полный активных абонентов, а плохо работает у одного). В этот момент спадают обращения и всё затихает. Кто-то обращает внимание (наконец-то), что все заявки на плохую работу были с одной и той-же моделью роутера, все дружно делают вид, что всё хорошо.
15:30 Снова наплыв заявок от абонентов, снова регистрация массовой аварии и передача админам. В этот момент становится ясно, что что-то действительно не так и нужно что-то делать (кто работал с клиентским сервисом меня поймет, как это иногда сложно сделать. Клиентывсегда врут, а иногда и первая линия врет, чтобы эскалировать задачу дальше).
15:35 Дежурный инженер получает заявку на проблему с клиентским сервисом. Получает список всех клиентов, тип их подключения и модель устройства. А дальше начинается немного магии.
15:40 Инженер прогоняет список клиентов через все диагностики какие есть, каждый роутер был проверен по всем стандартным метрикам и… ничего не нашлось. Роутер как роутер. Да, увеличилось CPU, но показатели не критичные, да он льет куда-то трафик, значит — работает.
Да, крутится на 52869 порту UPnP-сервис. Да там еще куча открытых портов, открыты значит нужны (логика железная), и он всегда там крутился и никаких проблем не было (еще один аргумент железной логики). Прямой ssh на данную модель роутера невозможен (откровенно говоря возможен, но внутри сильно урезанный busybox и политикой компании крайне не приветствовалось такое хождение по клиентским устройствам). Всё опять встало.
16:00 Только сейчас мы узнаем о том, что есть какие-то проблемы. Дежурный инженер докладывает своему руководителю, а руководитель телефонным звонком сообщает нам свои догадки по поводу 52869 порта и просит помочь.
16:05 Дальше всё происходило очень быстро. На тестовый стенд включается такая же модель роутера, у проблемного клиента забирается ip-адрес и вешается на тестовый. Включается wireshark. Это чтобы отловить запросы к устройству.
Чтобы отловить запросы от роутера (на тот момент еще неизвестна была общая схема, как происходит взаимодействие) клиент изолируется в тестовом сегменте и весь его трафик миррорится в ближайшую тестовую машину где поднят еще один wireshark.
Дальше ждем, смотрим в экран.
Таким способом уже ловили взломы — достаточно эффективно и поэтому решили не изменять привычкам.
16:10 Пока wireshark шуршит, в гугле находится уязвимость CVE-2014-8361 о чем сообщается инженерам. Инженер, не дослушав, принимает решение (и в принципе логичное) — фильтр данного порта на бордерах. Сказанно — сделано.
16:25 Нам сообщают, чтовсе говно миша переделывай не сработало. И мы уже знали, что не сработает. К тому моменту на тестовый роутер уже постучались, подняли реверс-шел на другом порту и начали параллельно использовать для DDOS-a через 1900(!) порт используя еще одну уязвимость. Господи, како же дырявое помойное ведро
Самое интересное — были изменены правила файрвола на устройстве и nmap теперь не показывал открытые порты с внешки. Только в дампе трафика можно было обнаружить запросы по этим портам. Т.е. злоумышленник после взлома закрывал доступ для остальных. Не хай-тек подход, но всё равно — браво.
16:30 Собирается конфа с вопросами «кто виноват и что делать». Оставили забаннеными порты 1900 и 52869. Принимаются попытки уже на взломанных устройствах что-то исправить. Ребут — не помог, идею перепрошить сразу отвергли. Да, функционал такой имеется, можно было одной кнопкой на всех устройствах переставить удаленно ПО через TR069. Но т.к. устройство не первой свежести, а количество клиентов было большим — определенный процент окирпиченных устройств создал бы проблем.
16:40 Подводим краткий итог: устройства взломаны, участвуют минимум в ddos и по шифрованному каналу куда-то что-то передают. (Все на разных портах). Залезть внутрь не представляется возможным, вендор отказал в полном доступе по ssh к устройству и посмотреть, что именно там накрутили невозможно. Консоль запаролена.
Где-то ближе к 17:00 Было принято решение шить устройства как самый быстрый способ. После перепрошивки и перезагрузки — всё нормализовалось.
К сожалению, так до конца решить эту проблему мы не смогли.
Под «решить» я подразумеваю получить полную информацию по взлому и обновить наши политики для противодействия подобному в дальнейшем. Да, не все поставленные задачи решаются успешно и так как хотелось бы. Это нормально. Хоть и обидно.
Если хорошо поискать на шодане,
то можно найти себе что-нибудь
для экспериментов:
так или так
но я вам этого не говорил.
Речь в статье пойдет об одной старенькой, но, как оказалось, ни разу не потерявшей актуальности и по сей день, дыре UPnP.
P.S. Провайдера называть не буду, вины его в этом нет, но с другой стороны есть явный недосмотр политик безопасности, которые вкупе с архитектурой сети дали возможность проэксплуатировать эту уязвимость. Как это всегда бывает — звезды сошлись. Провайдер ставил на своей сети роутеры клиентам с нужными чипами и подключал с внешним ip адресом. Да, большинство портов были зафильтрованы, но почему-то не 52869.
P.P.S. Все события произошли в конце 2018 года. Герои вымышлены, а совпадения с реальными личностями случайны.
Краткий ликбез:
Есть некоторая библиотека libupnp для разработки, которая «используется на тысячах устройств и называется Intel SDK для UPnP-устройств или Portable SDK для UPnP-устройств».
На английском:
На английском:
«The portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification and support several operating systems like Linux, *BSD, Solaris and others.»
Первое упоминание об уязвимости было в далеком 2014 году: тык
Попытки связаться с производителем особого успеха не принесли и уязвимость была опубликована. Единственной рекомендацией по противодействию было:
"… ограничение взаимодействия со службой… Только клиенты и серверы, которые имеют законные процедурные отношения… должны иметь возможность общаться с ним."Недостаток существует в сервисе miniigd SOAP. Проблема заключается в обработке запросов NewInternalClient из-за невозможности очистки пользовательских данных перед выполнением системного вызова. Злоумышленник может использовать эту уязвимость для выполнения кода с привилегиями root.
Т.е. на всех роутерах с версией UPnP 1.0 можно выполнять произвольный удаленный код.
Без авторизации. От рута. Здорово, правда?
Любой желающий может на github'е найти готовый плагин для метасплоита, работоспособность которого проверена прожженными стульями наших дежурных инженеров.
Было неожиданно и совсем не весело.
Краткая хронология событий того дня:
14:00 В техническую поддержку начинают поступать обращение абонентов на плохо работающий интернет.
- Симптомы со стороны клиента: «медленно работает, после перезагрузки какое-то время работает нормально, потом снова медленно».
- Симптомы со стороны оборудования: небольшой всплеск трафика и загрузки CPU были списаны на нагрузку, которую генерирует сам клиент.
Регистрируются одиночные заявки для проверки линии на админов, либо на выезд монтажника. Никакого общего шаблона для действий нет. Ничего не понятно.
15:00 Количество заявок начинает превышать среднюю температуру по больнице и одиночные заявки начинают лепить в заявки по больше с типом «Авария». Заявки передаются на старших администраторов для проверки сегментов сети.
15:20 Админы закрывают массовые аварии, т.к. проблем на сети нет, все заявки клиентов с разных точек подключения и одиночные. (к примеру: коммутатор полный активных абонентов, а плохо работает у одного). В этот момент спадают обращения и всё затихает. Кто-то обращает внимание (наконец-то), что все заявки на плохую работу были с одной и той-же моделью роутера, все дружно делают вид, что всё хорошо.
15:30 Снова наплыв заявок от абонентов, снова регистрация массовой аварии и передача админам. В этот момент становится ясно, что что-то действительно не так и нужно что-то делать (кто работал с клиентским сервисом меня поймет, как это иногда сложно сделать. Клиенты
15:35 Дежурный инженер получает заявку на проблему с клиентским сервисом. Получает список всех клиентов, тип их подключения и модель устройства. А дальше начинается немного магии.
спойлер
Которая, кстати, не сработала и главного мага потом уволили (но говорят, что не за это).
15:40 Инженер прогоняет список клиентов через все диагностики какие есть, каждый роутер был проверен по всем стандартным метрикам и… ничего не нашлось. Роутер как роутер. Да, увеличилось CPU, но показатели не критичные, да он льет куда-то трафик, значит — работает.
Да, крутится на 52869 порту UPnP-сервис. Да там еще куча открытых портов, открыты значит нужны (логика железная), и он всегда там крутился и никаких проблем не было (еще один аргумент железной логики). Прямой ssh на данную модель роутера невозможен (откровенно говоря возможен, но внутри сильно урезанный busybox и политикой компании крайне не приветствовалось такое хождение по клиентским устройствам). Всё опять встало.
16:00 Только сейчас мы узнаем о том, что есть какие-то проблемы. Дежурный инженер докладывает своему руководителю, а руководитель телефонным звонком сообщает нам свои догадки по поводу 52869 порта и просит помочь.
16:05 Дальше всё происходило очень быстро. На тестовый стенд включается такая же модель роутера, у проблемного клиента забирается ip-адрес и вешается на тестовый. Включается wireshark. Это чтобы отловить запросы к устройству.
Чтобы отловить запросы от роутера (на тот момент еще неизвестна была общая схема, как происходит взаимодействие) клиент изолируется в тестовом сегменте и весь его трафик миррорится в ближайшую тестовую машину где поднят еще один wireshark.
Дальше ждем, смотрим в экран.
Таким способом уже ловили взломы — достаточно эффективно и поэтому решили не изменять привычкам.
16:10 Пока wireshark шуршит, в гугле находится уязвимость CVE-2014-8361 о чем сообщается инженерам. Инженер, не дослушав, принимает решение (и в принципе логичное) — фильтр данного порта на бордерах. Сказанно — сделано.
спойлер
Это не сработало.
16:25 Нам сообщают, что
еще ликбез
Использование в DDoS атаках схемка
В 2014 неожиданно обнаружили, что SSDP использовался в DDoS атаках типа «Атака отражения и усиления при помощи SSDP» (SSDP reflection attack with amplification). Многие устройства, в том числе бытовые маршрутизаторы имели изъян в программном обеспечении UPnP, который позволял атакующему направлять ответы с порта 1900 на произвольный адрес в сети Интернет. В случае использования ботнета из многих тысяч подобных устройств, атакующий мог создать большой поток пакетов, достаточных для занятия пропускной полосы и насыщения каналов передачи данных атакуемой площадки, что приводит к отказу в обслуживании для обычных пользователей.
В 2014 неожиданно обнаружили, что SSDP использовался в DDoS атаках типа «Атака отражения и усиления при помощи SSDP» (SSDP reflection attack with amplification). Многие устройства, в том числе бытовые маршрутизаторы имели изъян в программном обеспечении UPnP, который позволял атакующему направлять ответы с порта 1900 на произвольный адрес в сети Интернет. В случае использования ботнета из многих тысяч подобных устройств, атакующий мог создать большой поток пакетов, достаточных для занятия пропускной полосы и насыщения каналов передачи данных атакуемой площадки, что приводит к отказу в обслуживании для обычных пользователей.
Самое интересное — были изменены правила файрвола на устройстве и nmap теперь не показывал открытые порты с внешки. Только в дампе трафика можно было обнаружить запросы по этим портам. Т.е. злоумышленник после взлома закрывал доступ для остальных. Не хай-тек подход, но всё равно — браво.
16:30 Собирается конфа с вопросами «кто виноват и что делать». Оставили забаннеными порты 1900 и 52869. Принимаются попытки уже на взломанных устройствах что-то исправить. Ребут — не помог, идею перепрошить сразу отвергли. Да, функционал такой имеется, можно было одной кнопкой на всех устройствах переставить удаленно ПО через TR069. Но т.к. устройство не первой свежести, а количество клиентов было большим — определенный процент окирпиченных устройств создал бы проблем.
16:40 Подводим краткий итог: устройства взломаны, участвуют минимум в ddos и по шифрованному каналу куда-то что-то передают. (Все на разных портах). Залезть внутрь не представляется возможным, вендор отказал в полном доступе по ssh к устройству и посмотреть, что именно там накрутили невозможно. Консоль запаролена.
Где-то ближе к 17:00 Было принято решение шить устройства как самый быстрый способ. После перепрошивки и перезагрузки — всё нормализовалось.
Вместо итогов
К сожалению, так до конца решить эту проблему мы не смогли.
Под «решить» я подразумеваю получить полную информацию по взлому и обновить наши политики для противодействия подобному в дальнейшем. Да, не все поставленные задачи решаются успешно и так как хотелось бы. Это нормально. Хоть и обидно.
Если хорошо поискать на шодане,
то можно найти себе что-нибудь
для экспериментов:
так или так
но я вам этого не говорил.
