Что такое обнаружение ssdp
Что такое обнаружение ssdp
SSDP (Simple Service Discovery Protocol) — сетевой протокол, используемый в небольших сетях, в том числе домашних, для анонсирования и выявления сетевых сервисов, в первую очередь поддерживаемых архитектурой Universal Plug-and-Play (UPnP). SSDP представляет собой текстовый протокол на базе HTTPU, использующий XML. Обмен сообщениями в нем осуществляется посредством датаграмм UDP.
Оглавление:
Подключил — и работает
Протокол SSDP является основой архитектуры UPnP. Он позволяет легко связывать между собой домашние устройства, работающие в рамках одной небольшой сети или подключенные к одной точке Wi-Fi. Среди таких устройств могут быть, например, смартфоны, принтеры и МФУ, умные телевизоры, медиаприставки, колонки, видеокамеры и пр. Чтобы SSDP работал, эти устройства должны поддерживать UPnP.
На устройствах и ПК, поддерживающих SSDP, эту функцию можно включить, отключить или приостановить. При включенной функции SSDP устройства сообщают информацию о себе и предоставляемых сервисах любому другому клиенту UPnP. Применяя SSDP, информацию о доступных сервисах предоставляют и компьютеры, подключенные к сети.
С помощью SSDP устройства и ПК не только «узнают» друг о друге, но и получают возможность каким-то образом взаимодействовать: обмениваться данными, запускать функции и сервисы на другом устройстве и пр.
Угрозы, связанные с SSDP
Однако необходимо помнить об обеспечении ИБ, поэтому нужно знать, что, во-первых, сам по себе протокол SSDP не обеспечивает шифрования (хотя, конечно, не препятствует устройствам обмениваться зашифрованными данными), и, во-вторых, во многих устройствах, предназначенных для использования в домашних условиях или небольшом офисе, функция поддержки SSDP по умолчанию включена, что создает риски несанкционированного доступа. Следовательно, эту функцию нужно держать отключенной, а включать лишь тогда, когда она реально нужна, и следить за тем, чтобы она была отключена на каждом устройстве, которое в данный момент ее не использует.
Проверить, включена ли служба обнаружения SSDP на вашем ПК под управлением Windows, можно с помощью команды services.msc. Чтобы убедиться в том, что поддержка SSDP включена на том или ином устройстве, следует внимательно изучить инструкцию к нему и проверить настройки.
Кроме того, необходимо помнить, что особенности SSDP могут быть использованы при реализации DDoS-атак типа «SSDP-амплификация».
DDoS-атаки с использованием SSDP
Эти атаки сетевого уровня (L3) используют уязвимости протокола SSDP, вероятно, ставшие следствием стремления его разработчиков максимально упростить взаимодействие устройств в небольшой сети. К сожалению, эта простота реализована в ущерб безопасности.
В самом общем виде подключение нового устройства выглядит следующим образом. Чтобы узнать, какие из устройств уже присутствуют в сети, добавляемое в нее устройство с включенной функцией SSDP отправляет поисковый запрос к другим устройствам на зарезервированный адрес и порт (239.255.255.250:1900), применяя «веерную рассылку», или мультивещание. В запросе устройство указывает соответствующий своему типу шаблон, или цель. В ответ на запрос каждое из имеющихся в сети устройств, поддерживающих в данный момент SSDP, отправляет UDP-сообщение с информацией о себе на IP-адрес источника и порт, с которого был отправлен запрос.
Фокус в том, что в рамках протокола SSDP проверка местоположения отправителя сообщения не производится, поэтому устройства готовы отвечать не только на запросы «соседей», но и на запросы, отправленные извне. Исключить такие запросы может и должен межсетевой экран (он же брандмауэр или firewall). Но, во-первых, владельцы сети далеко не всегда его устанавливают, и во-вторых, в установленном межсетевом экране порт 1900 нередко остается открытым. И поскольку ответ на запрос SSDP может быть в разы, а то и в десятки раз длиннее, чем сам запрос, становится возможной атака с усилением (SSDP-амплификация): фальшивый запрос, «прилетевший» из внешней сети и содержащий в качестве обратного IP-адреса адрес узла-жертвы, может вызвать многократно усиленный ответ и отправить его жертве. Ну а дальше — как в классическом сценарии DDoS: либо канал связи узла-жертвы окажется забит «мусором», либо сам узел «захлебнется», пытаясь обработать мощный поток SSDP-ответов.
Чтобы минимизировать атаки на основе SSDP, необходимо:
Отключаем потенциально опасные службы Windows
13.11.2017 2 мин. чтения
С целью обеспечения безопасности вашего компьютера необходимо отключать некоторые потенциально опасные службы Windows. Кроме того, отключение некоторых служб позволяет немного ускорить работу вашего персонального компьютера.
Где находится список служб Windows?
Открыть окно администрирования служб можно несколькими вариантами:
Как отключить службы Windows?
У нас открылось окно со списком всех служб Windows. Каждая служба имеет свое название и описание, где есть информация за что служба отвечает.
Чтобы отключить службу необходимо дважды нажать на нужной службе. После чего откроется окно с настройками службы.
В открывшемся окне необходимо изменить тип запуска на «Вручную» или «Отключена».
После чего необходимо остановить службу, нажав на соответствующую кнопку «Остановить».
Какие службы Windows отключать?
Отключать службы нужно аккуратно. Убедитесь, что работа той или иной службы не требуется для функционирования каких-либо нужных вам служб, приложений или устройств.
Перед отключением службы необходимо посмотреть какие службы зависят от отключаемой. Для просмотра зависимостей необходимо зайти в настройки службы и перейти во вкладку «Зависимости». Верхний список служб — это службы от которых зависит выбранная служба, нижний — какие службы зависят от выбранной службы.
Если списки пустые, то можно смело отключать службу.
Потенциально опасные службы Windows, которые используются для внешних атак
Удаленный реестр (RemoteRegistry) — позволяет удаленным пользователям изменять параметры реестра на вашем компьютере. Если остановить службу, то реестр может быть изменен только локальными пользователями, работающими на компьютере.
Службы терминалов (TermService) — служба предназначена для удаленного подключения к компьютеру по сети. Данная служба является основной для удаленного рабочего стола, удаленного администрирования, удаленного помощника и служб терминалов.
Служба обнаружения SSDP (SSDPSRV) — служба предназначена для обнаружения UPnP-устройств в домашней сети. UPnP (Universal Plug and Play) — универсальная автоматическая настройка и подключение сетевых устройств друг к другу, в результате чего сеть может стать доступной большому числу людей.
Планировщик заданий (Shedule) — данная служба позволяет настраивать расписание автоматического выполнения задач на компьютере. Автоматически запускает различные программы, скрипты и т. п. в запланированное время. Часто используется вирусами для автозагрузки или для отложенного выполнения. Многие легальные программы используют данную службу для своей работы, например антивирусы для ежедневного обновления антивирусных баз. Посмотреть список заданий можно тут: Пуск — Программы — Стандартные — Служебные — Назначенные задания.
Диспетчер сеанса справки для удаленного рабочего стола (Remote Desktop Help Session Manager) — служба управляет возможностями Удаленного помощника.
Telnet (Telnet) — позволяет удаленному пользователю входить и запускать программы, поддерживает различные клиенты TCP/IP Telnet, включая компьютеры с операционными системами Unix и Windows. Обеспечивает возможность соединения и удалённой работы в системе по протоколу Telnet (Teletype Network) с помощью командного интерпретатора. Данный протокол не использует шифрование и поэтому очень уязвим для атак при применении его в сети. Если эта служба остановлена, то удаленный пользователь не сможет запускать программы.
Вторичный вход в систему (Seclogon) — служба позволяет запускать процессы от имени другого пользователя.
Поиск устройств в сети по SSDP с помощью Poco
В данной небольшой заметке-примере я опишу как найти устройства в сети по протоколу SSDP (Simple Service Discovery Protocol) используя библиотеку Poco на C++.
Оговорю, что в платную полную версию Poco входят классы для работы UpnP. Но для моих целей вполне хватило базовой версии Poco, которая и так умет работать с UDP.
На счет протокола SSDP, он довольно старый единственной нормальной документацией по нему которую я смог найти оказался черновик официальной спецификации. С довольной большим количеством буковок. 😉
Суть работы протокола следующая:
Послать в сети широковещательный (broadcast) запрос — UDP пакет по адресу 239.255.255.250, порт назначения 1900.
Само тело запроса (пакета) можно посмотреть в исходном коде. Оговорюсь, что единственным полем, значение которого возможно придется меня это ST: в нем указывается тип устройств от которых мы хотим получить ответ.
Так как это протокол UDP, тут нет гарантированного ответа как вы могли привыкнуть при работе с HTTP. HTTP работает по принципу запрос-ответ.
В нашем же случае просто все устройства которые анонсируют себя в сеть, посылают UDP пакет в ответ на адрес с которого был послан запрос, ВАЖНО, ответ приходит не на 1900 порт, а на порт с которого был послан запрос (Source Port).
Так как UPD не дает никаких гарантий кроме целостности самих пакетов. То будем на протяжении 3 секунд слушать Socket (порт) с которого был отправлен запрос.
Собираем все ответы, а потом парсим ответы с помощью регулярных выражений с той же библиотеки Poco.
Есть другой вариант, просто слушать MulticastSocket, этот вариант приведен в документации к Poco на странице 17.
Но мне он не подошел, так как искомое мной устройство не анонсируют себя в сеть.
В запросе поле ST может принимать значения:
Также оговорюсь, что C++ для меня новый язык.
Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с
В мае мы поделились статистикой по самым популярным атакам с отражением. Тогда средний размер атаки SSDP был в районе 12 Гбит/с, а крупнейшая атака SSDP с отражением была такой:
График пакетов в секунду:
Использование полосы:
Пакетный флуд продолжался 38 минут. Судя по выборке потока данных, использовались 930 тыс. отражающих серверов. По нашей оценке, каждый рефлектор отправил 120 тыс. пакетов на Cloudflare.
Отражающие сервера располагались по всему миру, больше всего в Аргентине, России и Китае. Вот уникальные IP-адреса по странам:
Распределение IP-адресов по ASN вполне типично. Оно во многом соотносится с крупнейшими в мире домашними интернет-провайдерами:
Впрочем, что такое SSDP?
Данная атака состоит из UDP-пакетов с порта 1900. Этот порт используется протоколами SSDP и UPnP. UPnP — один из протоколов Zeroconf (Zero Configuration Networking), которые создают IP-сеть без конфигурации или специальных серверов. Скорее всего, ваши домашние устройства поддерживают его, чтобы их легче было найти с компьютера или телефона. Когда присоединяется новое устройство (вроде вашего ноутбука), оно может опросить локальную сеть на предмет наличия конкретных устройств, таких как интернет-шлюзы, аудиосистемы, телевизоры или принтеры. Подробнее см. сравнение UPnP и Bonjour.
UPnP плохо стандартизирован, но вот выдержка из спецификаций о фрейме M-SEARCH — основном методе обнаружения:
Когда в сеть добавляется контрольная точка, протокол обнаружения UPnP позволяет этой контрольной точке поиск интересующих устройств в сети. Он делает это с помощью мультивещания поискового сообщения на зарезервированный адрес и порт (239.255.255.250:1900) с шаблоном, или целью, соответствующей типу идентификатора для устройства или сервиса.
Ответы во фрейм M-SEARCH :
Чтобы быть найденным поисковым запросом, устройство должно отправить одноадресный ответ UDP на IP-адрес источника и порт, который прислал сообщение с помощью мультивещания. Ответ требуется, если в поле заголовка ST в запросе M-SEARCH указано “ssdp:all”, “upnp:rootdevice”, “uuid:”, а далее следует UUID, который в точности соответствует UUID устройства, или если запрос M-SEARCH соответствует типу устройства или типу сервиса, поддерживаемому устройством.
Так оно и работает на практике. Например, мой браузер Chrome регулярно опрашивает Smart TV, насколько я понимаю:
Этот фрейм отправляется на IP-адрес для мультивещания. Другие устройства, которые слушают этот адрес и поддерживают специфический многоэкранный тип ST (search-target), должны ответить.
Кроме запросов специфических типов устройств, существует два «общих» типа запросов ST :
В моей домашней сети отзываются два устройства:
Файрвол
Теперь, когда мы понимаем основы SSDP, будет легко понять суть атаки с отражением. На самом деле есть два способа доставки фрейма M-SEARCH :
Если дать нашему скрипту такую мишень с неправильной конфигурацией файрвола, то он отлично сработает через интернет:
Умножение пакетов
В этом конкретном случае единственный пакет SSDP M-SEARCH вызвал 8 пакетов в ответ. Просмотр в tcpdump:
Мишень совершила восьмикратное умножение пакетов и 26-кратное умножение трафика. К сожалению, это типичный случай SSDP.
Спуфинг IP
Последний шаг, необходимый для проведения атаки — убедить уязвимые серверы отсылать ответные пакеты на адрес жертвы, а не злоумышленника. Для этого злоумышленнику необходимо подделать IP-адрес отправителя в своих запросах.
Мы опросили IP-адреса рефлекторов, которые использовались в вышеупомянутой атаке на 100 Гбит/с. Оказалось, что из 920 тыс. адресов только 350 тыс. (35%) по прежнему отвечают на пробные запросы SSDP.
Ответившим на пробные запросы мы отправляли, в среднем, 7 пакетов:
Пакеты с запросами имели размер 110 байт. Пакеты с ответами — в среднем, 321 байт (± 29 байт).
Подробнее о серверах SSDP
Поскольку мы опросили уязвимые серверы SSDP, мы можем показать самые популярные значения заголовка Server :
104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0
77329 System/1.0 UPnP/1.0 IGD/1.0
66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2
12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
10827 miniupnpd/1.0 UPnP/1.0
8070 Linux UPnP/1.0 Huawei-ATP-IGD
7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4
7546 Net-OS 5.xx UPnP/1.0
6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5
5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4
4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0
4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4
2814 1.0
2044 miniupnpd/1.5 UPnP/1.0
1330 1
1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00
776 Upnp/1.0 UPnP/1.0 IGD/1.00
675 Unspecified, UPnP/1.0, Unspecified
648 WNR2000v5 UPnP/1.0 miniupnpd/1.0
562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0
518 Fedora/8 UPnP/1.0 miniupnpd/1.0
372 Tenda UPnP/1.0 miniupnpd/1.0
346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0
330 MF60/1.0 UPnP/1.0 miniupnpd/1.0
.
Самые популярные значения заголовка ST :
298497 upnp:rootdevice
158442 urn:schemas-upnp-org:device:InternetGatewayDevice:1
151642 urn:schemas-upnp-org:device:WANDevice:1
148593 urn:schemas-upnp-org:device:WANConnectionDevice:1
147461 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
146970 urn:schemas-upnp-org:service:WANIPConnection:1
145602 urn:schemas-upnp-org:service:Layer3Forwarding:1
113453 urn:schemas-upnp-org:service:WANPPPConnection:1
100961 urn:schemas-upnp-org:device:InternetGatewayDevice:
100180 urn:schemas-upnp-org:device:WANDevice:
99017 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:
98112 urn:schemas-upnp-org:device:WANConnectionDevice:
97246 urn:schemas-upnp-org:service:WANPPPConnection:
96259 urn:schemas-upnp-org:service:WANIPConnection:
93987 urn:schemas-upnp-org:service:Layer3Forwarding:
91108 urn:schemas-wifialliance-org:device:WFADevice:
90818 urn:schemas-wifialliance-org:service:WFAWLANConfig:
35511 uuid:IGD<8c80f73f-4ba0-45fa-835d-042505d052be>000000000000
9822 urn:schemas-upnp-org:service:WANEthernetLinkConfig:1
7737 uuid:WAN<84807575-251b-4c02-954b-e8e2ba7216a9>000000000000
6063 urn:schemas-microsoft-com:service:OSInfo:1
.
Уязвимые IP-адреса как будто принадлежат, в основном, домашним маршрутизаторам.
Открытый SSDP — это уязвимость
Само собой понятно, что разрешить входящий трафик 1900/UDP из интернета на ваш домашний принтер или другое устройство — не самая лучшая идея. Эта проблема известна по крайней мере с января 2013 года:
Клиенты Cloudflare полностью защищены от атак SSDP и других атак с умножением класса L3. Эти атаки хорошо отражаются инфраструктурой Cloudflare и не требуют дополнительных действий. Однако увеличение размера SSDP может стать серьёзной проблемой для других пользователей интернета. Мы должны призвать своих интернет-провайдеров запретить IP-спуфинг в своих сетях, включить поддержку BGP flowspec и настроить сбор потока данных в сети (netflow).
Статью подготовили совместно Марек Майковски и Бен Картрайт-Кокс.
Easy Hack: Хакерские секреты простых вещей
Содержание статьи
Собрать информацию по заголовкам email
Решение
Технологий становится все больше и больше. Они рождаются, меняются, исчезают и перерождаются. Все это создает большой ком, который растет и растет. Зачастую во многих компаниях разобраться с тем, что вообще используется в корпоративной инфраструктуре, — уже большая задача, не говоря о том, чтобы это все безопасно настроить… Это я к тому, что мест, через которые мы можем что-то где-то поломать или хотя бы выведать, — огромное количество. Сегодня этого мы и коснемся. И первым примером будет электронная почта.
WARNING
Как сервис она была придумана много лет назад. В ее основе лежит протокол SMTP, функционирующий на двадцать пятом TCP-порту. Принцип его работы выглядит примерно так. Мы, используя свой почтовый клиент, подключаемся к почтовому серверу (Mail Transfer Agent) по SMTP и говорим, что хотим отправить письмо на такой-то адрес. MTA принимает от нас письмо и подключается к тому MTA-серверу (опять по SMTP), куда мы посылаем письмо. IP-адрес удаленного MTA наш MTA получает из MX-записи той доменной зоны, куда мы шлем письмо (то, что идет в email после @). Найти MX-запись (читай — MTA) для любого домена очень просто:
Так работает почта
Хакер #181. Вся власть роботам!
Ты даже сам можешь отправить письмо, используя ncat или Telnet. Все, что потребуется, — это четыре команды: HELO, MAIL TO, RCPT TO, DATA (хотя есть ряд ограничений в зависимости от настроек сервера). Также стоит отметить, что каждое письмо имеет заголовки и тело сообщения. Заголовки только частично отображаются конечному пользователю (например, «Subject:») и используются, например, при возврате письма из-за проблем в конечном MTA.
Но самое важное, что фактически письмо проходит больше чем через один MTA и каждый из них добавляет ряд своих заголовков. Причем здесь все очень и очень «разговорчивы». Например, если письмо приходит из какой-то корпоративной сети к нам на почту, то мы, скорее всего, увидим в заголовках IP-адрес оправившего его пользователя (то есть того, кто подключился к внутреннему MTA в корпоративной сети) и версию используемого почтового клиента. Далее мы увидим данные уже самого MTA: IP-адрес (или имя в корпоративном домене), версию серверного ПО. А после этого очень часто — аналогичную запись, но уже по другому сетевому интерфейсу MTA.
Вдобавок к этому можно часто увидеть версию корпоративного антивируса, проверяющего всю почту, или применяемого спам-фильтра, а также характеристики детекта спама. Все это можно задействовать для более заточенных атак с использованием социальной инженерии. Например, в определенных ситуациях мы можем заранее «отслеживать» вероятность, что наше письмо попадет в спам. Кстати, если ты посылаешь письмо через какой-то веб-сайт (например, mail.ru), то твой IP тоже можно будет увидеть в заголовках.
Итог. Отправляем одно письмо секретарше в какую-то компанию, та нам отвечает. И мы уже знаем, что да как у них там :).
Посмотрим, что мы можем узнать из спама ВТБ24
Получить список доменов
Решение
Продолжим сбор информации. Давай представим себе компанию, которую мы хотим поломать снаружи. Одна из первых задач для пентеста через интернет — получить список доменных имен / виртуальных хостов. Методов много, и они стары как мир: обратный резолв IP, перебор имен, гуглохакинг. И ни один из них не дает полного результата, так что попробуем использовать их все вместе, попутно добавив чего-нибудь новенького :).
«Новенькое» — это сбор информации об именах с помощью SSL. Итак, давай вспомним основу. При подключении по SSL к любому серверу он возвращает нам свой сертификат. Сертификат — это набор полей (в том числе и открытый ключ сервера), подписанный корневым центром сертификации. В нем также есть поле CN (Common Name), где содержится имя сервера, на который выдан данный сертификат. Это уже что-то.
Например, когда мы сканируем по IP-адресам сеть и находим какой-то HTTP-сервер, то часто мы можем получить от него ответ с ошибкой (403). Все правильно, ведь мы не знаем, что указывать в заголовке Host HTTP-запроса. Тут-то нам и пригодится имя сервера. Посмотрим в SSL-сертификат, и вуаля — мы уже знаем, что подставить в заголовок.
Но это еще не все. Есть еще одно малоизвестно поле того же сертификата — SubjectAltName. Оно позволяет задавать альтернативные имена. То есть фактически один ключик может быть использован для совсем разных имен. Смотри рисуночки, и все станет ясно.
Собираем имена хостов из SSL
Получается, что вроде бы из «секьюрити»-фишки мы достаем крупицы интересующей нас информации. Отмечу еще из личного опыта, что иногда в сертификаты попадает информация и о внутренних именах хостов.
Атаковать с использованием техники session puzzling
Решение
Логические уязвимости — это всегда весело. Они бывают простыми и сложными, но их объединяет одно — необходимость правильно подумать. Вот только есть с ними и небольшая проблема: их как-то не особо типизируют (возможно, как раз-таки потому, что они все такие разнообразные :)). Ну да ладно. Хочу рассказать тебе об интересной технике (или виде уязвимостей, это уж как посмотреть), которую презентовали относительно недавно, пару лет назад. Название ей — session puzzling или session variable overloading (по версии OWASP).
Для начала давай вспомним, как веб-приложения аутентифицируют и авторизуют пользователя (HTTP ведь stateless).
Все выглядит вполне четко, но здесь пропущен важный момент. Он состоит в том, что сервер хранит у себя информацию о сессии конкретного пользователя. То есть приходит кука от юзера, он берет ее и смотрит (в памяти, в БД — в зависимости от ПО), а что же к ней у него «привязано». Простейший пример: он может хранить имя пользователя в сессии. И по куке получать из сессии имя и точно знать, кто к нему обратился в данный момент.
Вообще, в сессии хранят обычно «временную» информацию, а что-то более-менее постоянное — уже в БД. Например, логично хранить имя юзера в сессии, а вот его «роль» можно хранить в БД и запрашивать только по необходимости. Здесь, на самом деле, многое зависит от конкретного приложения и разработчика ПО.
Например, хранение большого объема данных в сессии может привести к исчерпанию либо памяти веб-сервера (Tomcat), либо свободного места на жестком диске (PHP). С другой стороны, обращения в БД требуют больше времени. Обусловлен выбор обычно производительностью, и о безопасности здесь редко думают (конечно, ведь как можно повлиять на то, что хранится на серверной стороне?).
И вот мы подошли к самой сути данной атаки: в определенных ситуациях мы можем влиять на то, что хранится на сервере. В каких конкретно — это тоже зависит от ситуации. Чаще всего нам нужны несколько различных точек входа в приложения, данные из которых попадают в одну и ту же переменную сессии.
Я приведу классический пример, и все будет ясно. Та же ситуация, что описана выше. Клиент, который может входить в приватную зону на сайте через страницу логина. Сайт, который хранит имя клиента в сессии, а доступ к приватным страницам проверяет по имени пользователя из сессии.
Но добавим к этому страницу с восстановлением пароля, на которой ты должен ввести свое имя (1), а система в ответ задаст секретный вопрос (2), на который ты должен будешь ввести правильный ответ для сброса пароля (3). И, как ты вероятно уже понял, для того чтобы провести по этой последовательности тебя (от 1 до 3), сервер должен также воспользоваться сессией и хранить в ней имя пользователя.
Так вот, атака будет заключаться в том, что, когда мы заходим на страницу восстановления и вводим имя пользователя администратора, сервер в сессии отмечает, что юзер — админ, и выводит для админа секретный вопрос. Все! Мы можем ничего не вводить, а просто перейти на приватный раздел сайта. Сервер посмотрит сессию, увидит, что имя пользователя админа, и даст нам доступ. То есть во время восстановления пароля мы «поставили» необходимое нам значение и дальше пошли бороздить приватные части. Бага здесь и в том, что сайт использует одно имя переменной и при аутентификации, и при восстановлении пароля.
Сначала может показаться, что данный тип уязвимости — редкость. На самом деле это не так. Я лично находил такие в достаточно распространенных продуктах. Вот только не знал тогда, что это так называется.
Кстати, кроме обхода аутентификации, использовать данную технику можно для повышения привилегий или перескока шагов на многошаговых операциях…
Как искать такого типа баги? Фактически какой-то суперметодики для этого нет. Но в качестве начала необходимо выискать входные точки в приложение, имеющие потенциальную возможность влиять на значения в сессионных переменных. А дальше — мозг, руки и тесты, тесты, тесты.
Если заинтересовался или хочешь попробовать на специальном уязвимом приложении — прошу к авторам изначального ресерча.
Провести атаку с подделкой Host
Решение
Еще один пример почти логической веб-уязвимости. Она основана на возможности подделки заголовка Host HTTP-запроса. Точнее, на отсутствии его проверки веб-сайтом при его последующем использовании. Но по порядку.
Когда ты вводишь в браузере какое-то имя сайта, он подключается к полученному из имени IP-адресу и в HTTP-запросе обязательно использует заголовок «Host:», в котором указывает это имя. Часто веб-приложения берут значение из Host для построения путей до ресурсов (скриптов, картинок и прочего). Вероятно, это позволяет им работать без привязки к конкретному названию сайта. Вроде как таким образом работает Joomla, Drupal.
Вообще, с точки зрения безопасности, это немного странная, но неопасная ситуация. Казалось бы, да, подставив свое доменное имя в Host, мы можем сделать так, чтобы на ресурс загрузились бы наши JS-скрипты (считай — XSS). Но заставить чужой браузер сделать то же самое (то есть вставить неверный Host), по сути, невозможно. Так что с точки зрения SOP здесь все вроде вполне нормально.
Но недавно я прочитал интересный пример эксплуатации данной фичи. Представь себе страницу восстановления пароля. Вводишь имя почты, и на нее отправляется ссылка со случайным токеном для смены пароля (классическая ситуация). Так вот, мы также можем подставить свой Host в запросе, и тогда письмо, которое придет пользователю, будет содержать наш домен! И как только пользователь кликнет на данную ссылку, на наш домен он перейдет вместе с токеном, который мы можем быстренько использовать для смены пароля.
Конечно, здесь есть важное затруднение — требуется применить социальную инженерию. Пользователь, конечно, не должен кликать на все сообщения о сбросе пароля. Кроме того, есть ряд серверных ограничений, так как веб-серверы будут отказываться обрабатывать запросы для неизвестных им Host.
Но все же в этой атаке что-то точно есть.
Случай, когда значение Host возвращается как путь к ресурсам страницы
Поломать UPnP
Решение
Universal Plug and Play (UPnP) — это набор сетевых протоколов, которые были созданы для упрощения взаимного нахождения различными девайсами, а также для их взаимодействия. Девайсом в данном случае может быть почти все что угодно: роутер, принтер, smartTV, какие-то сервисы Windows… И хотя, возможно, термин UPnP кажется тебе незнакомым, фактически он очень и очень распространен.
С точки зрения примера взаимодействия можно посмотреть в сторону Skype или BitTorrent и Wi-Fi-роутеров. Первые с помощью UPnP могут найти роутер и отправить ему набор команд на проброс какого-то внешнего порта вовнутрь. Очень удобно получается: никаких заморочек с ручной настройкой port forwarding’а.
Но если посмотреть на это с нашей хакерской точки зрения, то здесь есть чем поживиться… UPnP как технология появился еще в начале 2000-х и, возможно, потому имеет приличный ряд огрехов с точки зрения безопасности. Отсутствие аутентификации, например. Но давай обо всем по порядку.
UPnP основывается на нескольких протоколах, а также, что важнее, на определенной логической последовательности:
Обнаружение устройств. И для этого используется протокол SSDP (Simple Service Discovery Protocol — UDP, 1900-й порт). Каждое устройство, поддерживающее UPnP и предоставляющее какой-то сервис, систематически отправляет SSDP Notify пакет на 1900 UDP на multicast-адрес 239.255.255.250. Формат данных пакетов — HTTP.
SSDP NOTIFY моего вай-фай-роутера
В нем он сообщает поддерживаемые стандарты, а также TCP-порт и URL до описания (XML) каждого из своих сервисов. Например, http://192.168.0.1:1900/igd.xml описывает возможности сервиса InternetGatewayDevice.
Кроме прослушки 239.255.255.250, мы «насильно» можем посылать M-SEARCH запросы на тот же 1900-й порт. UPnP-серверы должны будут ответить на данный запрос. Отвечают все тем же Notify-пакетом.
Итак, первая задача — это, по сути, получение списка UPnP-серверов, а также URL’ов до XML’ек, с полным описанием функциональных возможностей каждого из сервисов сервера. Это важно, так как и порт, и URL’ы могут быть различными у разных производителей.
Определение возможностей. Итак, из SSDP мы получаем список сервисов со ссылкой на их описание в формате XML. Для доступа к ним уже используется обычный HTTP. В данном файле идет описание каждого из сервисов, а также ссылки на XML-файлы со списком возможных действий для каждого из них. То есть в данном случае XML’ки — это просто статические описания всех возможностей сервисов, а также перечень входных точек в сервисы и необходимых данных для выполнения действий.
Контроль. Получив данные XML’ки, мы уже можем создавать SOAP-пакеты и посылать их на сервер по HTTP, выполняя, таким образом, какие-то действия на сервере.
Аутентификация, как я уже говорил, отсутствует, и сервер выполнит все действия, которые ему придут в SOAP-запросе.
А вот и SOAP-команда на проброс портов
В 2008 году GNUCitizen даже выложили специальную SWF’ку. Эта SWF’ка (Flash) посылала SOAP-запрос на роутер (его IP необходимо указать), чтобы тот прокинул произвольный внешний порт на порт хоста юзера-жертвы. И получается, что, как только юзер-жертва открывал сайт с данной SWF, флеш «пропиливал» дырку в роутере до юзера и мы могли его атаковать. Очень удобно!
К сожалению, данный способ больше не работает: с тех пор ужесточилась песочница Flash’а и мы уже не можем посылать произвольные POST-запросы (самое главное, нам надо добавить еще заголовок SOAPAction) на любой другой хост (так как сначала произойдет запрос на разрешающие правила в crossdomain.xml).
Итак, теперь, я думаю, мы видим, как это все работает. Давай еще посмотрим, что можно с этим сделать.
Во-первых, это прошитые возможности SOAP’а. Кроме примера с пробросом портов, есть случаи, когда мы можем сменить настройки роутера и выставить свой DNS-сервер. А это уже ого-го! Тут все зависит от конкретного устройства, сервисов и нашей фантазии.
Во-вторых, это приличный инф-дисклоуз: IP-адреса, версия девайса и UPnP-библиотек и прочее (в SSDP, HTTP-сервере и XML’ках) Вдобавок к этому многие прошитые возможности также могут нам что-то рассказать. Пароли, например. Как-то во время внешнего пентеста обнаружили доступный SSDP и накопали пучок приватной инфы о внутренностях компании.
В-третьих, мы можем поломать сами сервисы. Год назад Rapid7 сделали прикольнейшее исследование UPnP. Они просканили интернет на SSDP и на SOAP (на стандартных портах), пофингерпринтили их. Оказалось, что большинство UPnP-серверов построено на четырех SDK. Из них выделяются MiniUPnP и Portable UPnP (libupnp), на которых «держится» больше половины. Но что важнее, почти все серверы используют устаревшие версии библиотек, в каждой из которых есть пучок уязвимостей, в том числе приводящих к RCE. Причем и в SOAP’е, и в SSDP.
Кроме того, в этом исследовании показано, как на самом деле много таких устройств торчит наружу, хотя бы SSDP. То есть даже если тот же SOAP закрыт, мы можем захватить удаленный контроль над устройством через SSDP.
Конечно, здесь надо отметить, что с удаленным сплоитингом может быть не очень просто, так как устройства эти часто построены на всяких MIPS, ARM, что точно все затрудняет. К тому же придется бороться еще и с механизмами защиты памяти ОС (тот же ASLR). Но все-таки это возможно.
Что же нам надо, чтобы все поломать?
Тулз на деле немного. В метасплоите есть модуль для поиска UPnP (и детекта CVE по ним). Плюс есть два «комбайна», позволяющих выполнять SOAP-команды. Это Miranda и Umap. Оба написаны на Python’е, только под *nix и при этом не очень хорошо работают.
Надеюсь, прочтенное наполнило тебя энтузиазмом и жаждой жизни, так что если есть желание поресерчить — пиши на ящик. Всегда рад :). И успешных познаний нового!