Что такое Realtek SDK

Обновлено: 03.07.2024

Эти недостатки легко использовать, и их можно быстро интегрировать в существующие хакерские платформы, которые используют хакеры.

Серьезная уязвимость, обнаруженная в программном пакете SDK, используемом сотнями тысяч устройств на базе Realtek, теперь используется ботнетом на основе Mirai.

Уязвимость системы безопасности, обнаруженная исследователями из IoT Inspector, отслеживается как CVE-2021-35395 и имеет рейтинг серьезности 9,8/10. CVE-2021-35395, состоящая из шести различных ошибок, использовалась для распространения версии вредоносного ПО Mirai IoT.

Кто пострадал?

Исследователи выявили около 65 различных затронутых поставщиков и производителей почти 200 типов затронутых устройств. Некоторые из поставщиков: ASUS, Belkin, D-Link, Huawei, LG, Logitech, Netgear, ZTE и Zyxel. Здесь вы можете найти полный список затронутых поставщиков.

Согласно бюллетеню IoT Inspector, к затронутым устройствам относятся домашние шлюзы, туристические маршрутизаторы, ретрансляторы Wi-Fi, IP-камеры, интеллектуальные шлюзы Lightning и подключенные игрушки.

Поскольку эта уязвимость может повлиять на веб-интерфейс управления, удаленные киберпреступники могут взламывать устройства, чтобы удаленно выполнять произвольный код на тех, которые не были исправлены, что позволяет им взять на себя управление уязвимыми устройствами.

Даже если Realtek выпустила исправленную версию открытого SDK всего за несколько дней до выпуска рекомендации IoT Inspector, у людей, чьи устройства пострадали, не было достаточно времени, чтобы применить исправление.

По данным BleepingComputer, ботнет Mirai начал поиск устройств, на которых не было исправлено CVE-2021-35395, вскоре после того, как IoT Inspector опубликовал информацию об уязвимости.

По состоянию на 18 августа мы выявили попытки использования CVE-2021-35395 в реальных условиях.

Расширитель Netis E1+
Wi-Fi-маршрутизаторы Edimax N150 и N300
Маршрутизатор Repotec RP-WR5444

Эти устройства в основном используются для улучшения приема Wi-Fi.

Ранее в этом месяце исследователи Juniper Threat Labs начали замечать попытки использовать CVE-2021-20090, ошибку, которая затрагивает не менее 20 поставщиков, поставляющих маршрутизаторы с прошивкой, разработанной тайваньским поставщиком сетевых решений.

По данным Juniper Networks, этот злоумышленник активен как минимум с февраля.

Эта цепочка событий показывает, что хакеры активно ищут уязвимости, связанные с внедрением команд, и используют их для быстрого распространения широко распространенных вредоносных программ.

Такие уязвимости легко использовать и их можно быстро интегрировать. в существующие хакерские платформы, которые используют злоумышленники, задолго до того, как устройства будут исправлены и поставщики средств защиты смогут отреагировать.

Множественные уязвимости в программном обеспечении, используемом 65 вендорами, которые подвергаются активной атаке.

Субъекты угроз, сосредоточившиеся на уязвимостях внедрения команд, сообщили о наборах микросхем Realtek всего через несколько дней после того, как в пакетах разработчиков программного обеспечения (SDK), развернутых как минимум 65 отдельными поставщиками, было обнаружено множество недостатков.

16 августа исследовательская лаборатория IoT Inspector сообщила о нескольких уязвимостях Realtek. Злоумышленникам потребовалось около 48 часов, чтобы начать использовать их. SAM Seamless Network сообщила, что через два дня после того, как ошибки были обнародованы, злоумышленники предприняли «неоднократные» попытки взломать продукт компании Secure Home для распространения новой версии вредоносного ПО Mirai.

"В частности, мы заметили попытки взлома веб-страниц formWsc и formSysCmd", — говорится в отчете SAM об инциденте. «Эксплойт пытается развернуть вариант Mirai, обнаруженный в марте компанией Palo Alto Networks. Mirai — печально известное вредоносное ПО для Интернета вещей и маршрутизаторов, циркулирующее в различных формах в течение последних 5 лет. Первоначально он использовался для отключения больших участков Интернета, но с тех пор развился во множество вариантов для разных целей».
Далее отчет связывает другую подобную атаку с группой нападения. В отчете поясняется, что 6 августа компания Juniper Networks обнаружила уязвимость, которая всего два дня спустя также использовалась для попытки доставки того же ботнета Mirai с использованием той же сетевой подсети.

"Эта цепочка событий показывает, что хакеры активно ищут уязвимости, связанные с внедрением команд, и используют их для быстрого распространения широко распространенных вредоносных программ", — отмечает SAM. «Такие уязвимости легко использовать, и их можно быстро интегрировать в существующие хакерские платформы, которые используют злоумышленники, задолго до того, как устройства будут исправлены и поставщики средств защиты смогут отреагировать».

Корпорация Realtek Semiconductor.еще не ответила на запрос Threatpost о комментариях, но компания выпустила этот бюллетень по CVE-2021-35392, CVE-2021-35393, CVE-2021-35394, CVE-2021-35395,

За последние годы популярность исходного кода Mirai резко возросла: к марту прошлого года было обнаружено более 60 вариантов. Это число все еще растет благодаря последней итерации, направленной на устранение недостатков Realtek SDK.

Тагетинговые устройства

Учитывая количество затронутых поставщиков, исследователи обеспокоены тем, что у злоумышленников есть достаточно возможностей для первого шага, чтобы использовать ошибку до того, как будут развернуты исправления.

Расширитель Netis E1+
Wi-Fo-маршрутизаторы Edimax N150 и N300
Маршрутизатор Repotec RP-WR5444

В исходном отчете IoT Inspector такая уязвимость была связана с недавними атаками на цепочки поставок на SolarWinds и Kaseya.

"Поскольку среди экспертов по безопасности растет осведомленность о прозрачности цепочки поставок, этот пример является довольно хорошей демонстрацией обширных последствий малоизвестной цепочки поставок IoT, говорится в отчете IoT Inspector.

Всего через день после разоблачения Realtek компания Mandiant в сотрудничестве с Агентством кибербезопасности и безопасности инфраструктуры (CISA) сообщила об уязвимости в облачной платформе Интернета вещей ThroughTek Kalay. Уязвимость потенциально позволяла бы злоумышленнику завладеть устройством Интернета вещей, чтобы слушать живое аудио, смотреть видео в реальном времени и выполнять другие действия.

«Эти типы уязвимостей появляются каждый день, и, вероятно, есть еще много других, которые еще предстоит обнаружить…», — сообщил Threatpost по электронной почте Ран Хананель из SAM.

Защита Интернета вещей

Янив Бар-Даян, соучредитель Vulcan Cyber, сказал Threatpost, что безопасность IoT по своей природе сложна, потому что часто неясно, кто несет ответственность за данные.

"Несмотря на то, что ответственность за выпуск исправлений и исправлений ошибок на рынке должна лежать на плечах поставщиков, пользователи должны быть уверены, что пока полагаются на проверенные и надежные передовые методы обеспечения безопасности", – сказал Бар-Даян. «Шифруйте данные, используйте сложные и уникальные пароли или многофакторную аутентификацию, не сообщайте свой идентификатор сети, дважды проверяйте конфигурации и, прежде всего, своевременно и часто применяйте исправления».

Помимо исправления, Джейк Уильямс из BreachQuest рекомендует ограничить доступ веб-интерфейса к локальной сети.

"Это не остановит атаки, но ограничит возможности их проведения", – сказал Уильямс. «Это особенно верно для административных интерфейсов».

Разработчики также должны знать, что код, который они используют, безопасен. Спецификация программного обеспечения (SBOM) — это одно из решений, предложенных правительством США после взлома SolarWinds.

«Разработчики программного обеспечения любого типа любят использовать SDK, потому что они позволяют им внедрять возможности в свое программное обеспечение, не создавая его самостоятельно», — сказал Threatpost Хэнк Шлесс из Lookout. «Это широко практикуется, и существует определенный уровень доверия разработчиков к тем, кто создает эти SDK, что все, что в них упаковано, будет безопасным. Однако, как и у любого другого типа программного обеспечения, у SDK есть свои неизбежные недостатки».

В ходе исследовательского проекта, посвященного конкретному кабельному модему, мы обнаружили, что в системе используется конструкция с двумя однокристальными системами. На основной SoC работала система Linux, а на второй SoC — выделенном наборе микросхем Realtek RTL819xD, реализующем все функции точки доступа, — другая, урезанная система Linux от Realtek.

Чипсеты Realtek используются во многих встроенных устройствах в сфере Интернета вещей. SoC RTL8xxx, которые обеспечивают беспроводные возможности, очень распространены. Поэтому мы решили потратить время на идентификацию двоичных файлов, работающих на RTL819xD на нашем целевом устройстве, которые предоставляют услуги по сети и предоставляются самой Realtek. Такие двоичные файлы входят в состав Realtek SDK, разработанного Realtek и предоставляемого поставщикам и производителям, использующим SoC RTL8xxx.

Используя эти уязвимости, удаленные злоумышленники, не прошедшие проверку подлинности, могут полностью скомпрометировать целевое устройство и выполнить произвольный код с наивысшим уровнем привилегий.

Мы выявили не менее 65 различных затронутых поставщиков с почти 200 уникальными отпечатками пальцев благодаря возможностям сканирования Shodan и некоторым неправильным настройкам поставщиков и производителей, которые предоставляют эти устройства для доступа в Интернет. Затронутые устройства реализуют возможности беспроводной связи и охватывают широкий спектр вариантов использования: от домашних шлюзов, туристических маршрутизаторов, повторителей Wi-Fi, IP-камер до интеллектуальных шлюзов Lightning и даже игрушек с подключением.

< бр />

Ключевые выводы

Поскольку среди экспертов по безопасности растет осведомленность о прозрачности цепочки поставок, этот пример является довольно хорошей демонстрацией обширных последствий малоизвестной цепочки поставок IoT.В отличие от недавних атак на цепочку поставок, таких как Kaseya или Solar Winds, когда злоумышленники шли на многое, чтобы проникнуть в процессы выпуска релизов поставщика и разместить скрытые лазейки в обновлениях продуктов, этот пример гораздо менее изощренный и, вероятно, гораздо более распространенный, для трех простых причины:

Со стороны поставщика недостаточные методы безопасной разработки программного обеспечения, в частности отсутствие тестирования безопасности и проверки кода, привели к тому, что десятки критических проблем безопасности оставались нетронутыми в кодовой базе Realtek более десяти лет (от ветки 2.x до « Jungle" SDK в "Luna" SDK).
Со стороны поставщиков продуктов мы видим производителей, имеющих доступ к исходному коду Realtek (требование для создания двоичных файлов Realtek SDK для своей собственной платформы), которые не смогли достаточно проверить свою цепочку поставок, оставили проблемы незамеченными и распространили уязвимости среди сотни тысяч конечных клиентов, что делает их уязвимыми для атак.
Однако проблемы с цепочками поставок могут возникнуть и выше по течению. В ходе нашего исследования мы обнаружили, что исследователи безопасности и пен-тестеры ранее выявляли проблемы в устройствах, использующих Realtek SDK, но не связывали эти проблемы напрямую с Realtek. Поставщики, получившие сообщения об этих уязвимостях, исправили их в своих филиалах, но не уведомили Realtek, оставив незащищенными других.

Наша платформа анализа встроенного ПО IoT Inspector может помочь в обнаружении таких важных проблем в цепочке поставок. Он автоматически определяет, основана ли прошивка на уязвимом SDK Realtek, а также его конкретную версию. Он также может обнаруживать каждую уязвимость, о которой мы сообщали, а также то, было ли применено предоставленное исправление.

Пожалуйста, продолжайте читать, чтобы узнать все подробности нашего исследовательского процесса.

Уязвимости UPnP (mini_upnpd, wscd)

Обзор

Realtek отказалась от своей предыдущей службы UPnP miniigd в ответ на CVE-2014-8361. Впоследствии они предоставили исходный код для создания двух двоичных файлов с разными функциями в рамках своего SDK:

Вбросив в Google нужные ключевые слова, мы смогли получить доступ к исходному коду на Github. Это помогло ускорить идентификацию уязвимости, но мы уверены, что опытные реверс-инженеры придут к таким же выводам, учитывая, что некоторые двоичные файлы в нашем наборе образцов поставлялись с отладочными символами. Чтобы проиллюстрировать уязвимости, мы прокомментировали соответствующие разделы исходного кода.

Переполнение буфера стека из-за заголовка обратного вызова UPnP SUBSCRIBE

Несколько слов о подписке UPnP

Любая служба UPnP должна предоставлять список устройств, которыми она управляет, а также список служб, подключенных к этим устройствам. В приведенном ниже примере, взятом из документации gupnp (Writing a UPnP Service: GUPnP Reference Manual), мы видим виртуальное световое устройство с подключенной к нему службой переключения питания.

В строке 19 мы видим элемент eventSubURL, связанный с функцией UPnP: уведомление о событии.

Чтобы подписаться на уведомление о событии для службы, подписчик должен отправить запрос с помощью метода SUBSCRIBE вместе с заполненными полями заголовка NT и CALLBACK на полный URL подписки на событие этой службы.

Запрос UPnP SUBSCRIB E обычно выглядит следующим образом:

При возникновении событий служба UPnP уведомляет подписчика, отправляя запрос NOTIFY на предоставленный URL-адрес CALLBACK. В нашем примере событием может быть включение или выключение виртуального света другим клиентом UPnP.

Теперь, когда у вас есть некоторые сведения об уведомлениях о событиях UPnP и подписках, давайте рассмотрим реализацию Realtek SDK.

Функция GetIPandPortandCallback представлена ниже, чтобы вы могли попытаться найти уязвимость самостоятельно. Мы предоставляем подробное объяснение ниже.

Код синтаксического анализа GetIPandPortandCallBack неверен на многих уровнях, но давайте сосредоточимся на том, почему он уязвим:

он проверяет, начинается ли обратный вызов с ", и в противном случае переходит со строки 12 на строку 21.

Со строк с 26 по 67 начинается фактическое извлечение IP-адреса и номера порта:

он будет продвигаться в буфере до тех пор, пока не будет найдено ‘:’ или ‘/’, каждый раз, когда встречается ‘.’, счетчик увеличивается

при совпадении ‘:’ или ‘/’ проверяется, есть ли 3 точки (сильная проверка для IPv4, верно?)

если найден символ ‘/’, по умолчанию используется номер порта 80

если столкновение с символом ‘:’, чтение буфера продолжается до тех пор, пока не встретится символ ‘/’, и копирование буфера из ‘:’ в ‘/’ в буфер фиксированного размера с именем ‘port’

затем буфер порта передается atoi для получения целого числа

Уязвимость возникает в строке 58, где memcpy вызывается с длиной, которая может превышать размер буфера стека портов. Это связано с тем, что нет ограничений по размеру при определении раздела порта между символами «:» и «/» в обратном вызове.

Поэтому следующий запрос SUBSCRIBE вызовет переполнение:

Мы подтвердили это на нашем тестовом устройстве с помощью GDB. Как мы видим ниже, программный счетчик нашего процесса был перезаписан на «AAAA» (0x41414141):

Получение оболочки

Чтобы в полной мере продемонстрировать потенциал этой уязвимости, мы разработали быстрое доказательство концепции, позволяющее использовать обратную оболочку на целевом устройстве. Мы используем переполнение стека, используя технику ret2libc для запуска произвольной команды. Учитывая, что размер команды, которую мы можем запустить, ограничен 16 символами, мы просто запускаем демон UDPServer и используем внедрение команды, влияющее на эту службу, для запуска более длинной команды, которая извлекает полезную нагрузку из обратной оболочки через FTP и выполняет ее.

Переполнение буфера кучи из-за поля SSDP ST

Через SSDP можно отправлять сообщения двух типов:

M-SEARCH — отправляется клиентами, желающими найти доступные услуги в сети.

NOTIFY — отправляется серверами UPnP для уведомления об установлении или отзыве служебной информации группе многоадресной рассылки.

Обработка запросов SSDP осуществляется с помощью ProcessSSDPRequest , который анализирует только сообщения M-SEARCH и игнорирует сообщения NOTIFY.

Происхождение переполнения буфера кучи находится между строками 43 и 68, где обработчик SSDP сравнивает значение заголовка ST со своим внутренним списком открытых типов служб.

Защищенная реализация SSDP будет принимать только заголовок ST, который точно соответствует одному из открытых типов службы (например, upnp:rootdevice ). В этом случае сравнение производится с memcmp — но только до длины проверяемого в данный момент типа сервиса. Это означает, что мы можем пройти эту проверку, если хотя бы n байт предоставленного нами значения заголовка ST соответствуют типу службы (например, upnp:rootdevicewhateverfollows).

Затем в строке 57 функция вызывает SendSSDPAnnounce2, чтобы ответить на наш запрос M-SEARCH ответом NOTIFY, используя два входных данных, контролируемых пользователем: значение заголовка ST ( st ) и длину значения заголовка ST ( st_len ).

Переполнение происходит в SendSSDPAnnounce2 в строке 23 при вызове sprintf для помещения контролируемых пользователем данных в 512-байтовый буфер, выделенный в куче.

С помощью Scapy мы разработали следующую проверку концепции:

Мы подтвердили это на нашем тестовом устройстве с помощью GDB. Как мы видим ниже, счетчик программ нашего процесса сбился из-за наличия недопустимых значений в куче:

Эксплуатация кучи всегда сложнее, но двоичный файл предоставляет достойные примитивы для выполнения кучи. Если мы хотим написать полный PoC, нам нужно посмотреть, какие структуры выделяются в куче во время выполнения.

Уязвимости интерфейса веб-управления (сети, удавы)

Обзор

У Realtek есть две разные версии стандартного бинарного файла веб-интерфейса управления: одна — GoAhead-webs ( /bin/webs ), другая — Boa ( /bin/boa ).

На каждом сервере реализованы одни и те же функции с одинаковыми уязвимостями (внедрение команд, переполнения). Единственное отличие состоит в том, что разработчики Realtek используют разные API для реализации своих функций (например, websGetVar для получения параметра запроса в GoAhead-webs и req_get_cstream_var в Boa).

В состоянии по умолчанию интерфейс выглядит примерно так:

Веб-интерфейс Realtek SDK

Большинство поставщиков и производителей используют один из этих двоичных файлов веб-управления, но изменяют внешний вид пользовательского интерфейса, чтобы он отражал их бренд. В ходе нашего исследования было обнаружено, что некоторые из них также удаляют и/или вставляют пользовательские функции. Очевидным примером этого является интерфейс, обнаруженный на игрушечном танке IoT, проанализированный Pentest Partners:

Веб-интерфейс Realtek SDK на ESSON

Предупреждения

Веб-сервер уязвим для повторной привязки DNS и не реализует какую-либо защиту от CSRF. Это означает, что его можно использовать через Интернет, заставив жертву открыть веб-страницу, контролируемую злоумышленником, и угадать внутренний IP-адрес, на котором работает служба.

Двоичный файл реализует небольшую функцию проверки подлинности с помощью базы данных пользователей, сохраненной в файле .dat или .txt в зависимости от двоичного файла (webs или boa). Если поставщик явно не удалил в коде/конфигурации, существует учетная запись пользователя по умолчанию ( supervisor/supervisor ).

Возможность использования выявленных проблем зависит от действий конечного поставщика/производителя с веб-сервером Realtek SDK.Некоторые поставщики используют его как есть, другие добавляют свою собственную реализацию аутентификации, некоторые сохраняют все функции сервера, некоторые удаляют некоторые из них, третьи добавляют собственный набор функций.

Однако, учитывая, что реализация Realtek SDK полна небезопасных вызовов и что (из того, что мы видели до сих пор) разработчики склонны повторно использовать эти примеры в своем пользовательском коде, любой двоичный файл, основанный на веб-сервере Realtek SDK, вероятно, будет содержат свой собственный набор проблем поверх проблем Realtek (если они сохранены).

Прекрасным примером этого является реализация веб-сервера Edimax, которая сохранила уязвимости из обработчиков CGI Realtek SDK по умолчанию (например, переполнение буфера через параметр submit-url), но также скопировала этот точный код в свои собственные обработчики CGI (см. домашних устройств Edimax — Embedded Lab Vienna для Интернета вещей и безопасности).

Переполнение буфера стека через параметр запроса submit-url formRebootCheck

Переполнение буфера присутствует в formRebootCheck. Переполнение может быть вызвано отправкой слишком длинного параметра запроса submit-url:

lastUrl — это статический массив символов длиной 100 байт, хранящийся в разделе .data. Учитывая, что переменная выше GOT, мы можем воспользоваться этой уязвимостью, перезаписав запись GOT.

Простая демонстрация со значением submit-url длиной 3000 байт показана ниже:

Этот запрос снова вызовет segfault:

Переполнение буфера стека через параметр запроса formWsc submit-url

Аналогичная проблема присутствует в formWsc . Это переполнение также может быть вызвано отправкой слишком длинного параметра запроса submit-url:

Опять же, lastUrl — это статический массив символов длиной 100 байт, хранящийся в разделе .data. Учитывая, что переменная выше GOT, мы также можем переполнить эту уязвимость, перезаписав запись GOT.

Простая демонстрация со значением submit-url длиной 3000 байт показана ниже:

Тем не менее, будет вызван еще один сегментный отказ:

Переполнение буфера стека из-за параметра запроса formWlSiteSurvey ifname

Форма formWlSiteSurvey выполняет небезопасное копирование из контролируемого пользователем буфера в переменную фиксированного размера. WLAN_IF — это статический массив символов длиной 100 байт, хранящийся в разделе .data.

Впоследствии это приведет к segfault, за которым последует полная перезагрузка:

Полная перезагрузка, вероятно, связана с ioctl, выполняемым веб-сервером, который отправляет структуру, содержащую содержимое IFNAME, в драйвер ядра Realtek для получения статистики из беспроводного интерфейса.

Выполнение произвольной команды в formSysCmd

Форма formSysCmd представляет выполнение команды как функцию и обычно доступна через /goform/formSysCmd или /boafrm/formSysCmd в зависимости от используемого веб-сервера.

Можно возразить, что это скорее лазейка, чем уязвимая конечная точка, особенно когда поставщики склонны удалять представленную ниже HTML-страницу из своего интерфейса, но оставляют включенной конечную точку выполнения команд.

Форма Realtek SDK formSysCmd

Код формы предельно прост: получите команду через параметр запроса sysCmd, передайте ее в system() и верните результаты этой команды на следующей странице.

Эта «функция» — еще один отличный пример того, что возникает при распространении уязвимостей по цепочке поставок. Многие тестировщики обнаружили именно эту уязвимость в разных устройствах от разных производителей, но никогда не сообщали о ней в Realtek.

Внедрение команды через параметр запроса peerPin в formWsc

Форма formWsc уязвима для внедрения произвольных команд в нескольких местах. Все они связаны с контролируемым пользователем ПИН-кодом WPS, который передается системным командам без предварительной очистки.

Переполнение буфера стека через параметр запроса имени хоста formStaticDHCP

Форма formStaticDHCP уязвима для переполнения стека, когда контролируемое пользователем значение (параметр hostname) небезопасно копируется в переменную стека с помощью strcpy:

Переполнение буфера стека через параметр запроса submit-url formWlanMultipleAP

Форма formWlanMultipleAP уязвима для переполнения стека, когда контролируемое пользователем значение (параметр submit-url) небезопасно копируется в переменную стека с помощью sprintf :

Переполнение буфера стека из-за параметра запроса formWsc peerPin

Форма formWsc уязвима для переполнения стека, когда контролируемое пользователем значение ( параметр peerPin ) небезопасно копируется в переменную стека с помощью sprintf :

Двоичный файл просто выдаст ошибку сегментации:

Уязвимости UDP-сервера

Обзор

Следующая проблема с внедрением команд, обнаруженная в UDPServer, уже была обнаружена и описана в 2015 году Питером Адкинсом, но Mitre никогда не назначала CVE:

Один из наиболее «интересных» хуков, обнаруженных этими устройствами, позволяет запускать процесс UDPServer на устройстве при вызове. При запуске этот процесс прослушивает IP-адрес устройства в локальной сети для получения данных по UDP 9034.

К сожалению, этот процесс, по-видимому, не выполняет какую-либо очистку ввода перед передачей пользовательского ввода в вызов system(). Дальнейшее расследование показало, что источник для этой службы (UDPServer)
доступен в RealTek SDK и, по-видимому, является диагностическим инструментом.

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

Изучив последние образцы затронутого двоичного файла, мы обнаружили, что Realtek выпустила неполное исправление именно для этой проблемы. Мы также обнаружили несколько случаев переполнения буфера.

Предостережение

Некоторые устройства автоматически запускают UDPServer из своего сценария инициализации, некоторые выполняют его, когда вызывается определенная функция в их собственном коде (запрос веб-сервера, запрос к пользовательскому сетевому демону и т. д.), некоторые никогда не запускают его, а UDPServer просто остается как артефакт.

Для каждого идентифицированного образа микропрограммы с двоичным файлом UDPserver требуется ручной анализ, чтобы подтвердить, открыта ли служба по умолчанию или ее можно запустить.

Внедрение команд по протоколу UDPServer

Глядя на проверку концепции и текущий код, кажется, что Realtek пыталась исправить проблемы, о которых сообщалось в 2015 году. В 2015 году отправка \`telnetd -l /bin/sh\` в качестве полезной нагрузки UDP инициировал внедрение команды.

Наша интерпретация заключается в том, что Realtek пыталась исправить это, используя следующую конструкцию, которую мы видим в двоичном файле:

6 вызовов system() выполняются с пользовательским вводом. Каждый вызов имеет ту же структуру, что и ниже:

Статическое переполнение буфера через протокол UDPServer

Помимо внедрения команд, сервер уязвим к переполнению буфера из-за небезопасных вызовов sprintf (комментарии добавлены в качестве пояснения):

Эксплуатация не будет простой, учитывая, что переполненный буфер будет расположен в разделе .data (статическое объявление).

Присутствуют 3 других переполнения:

Выявление затронутых поставщиков

Для выявления устройств, затронутых уязвимостями, обнаруженными в службе UPnP/SSDP, мы можем положиться на Shodan.

После некоторых исследований мы пришли к выводу, что Shodan делает следующее:

Название модели, номер и описание представлены Shodan как аспект «продукта». Зная это, мы можем получить информацию обо всех производителях и названиях моделей, предоставляющих услуги SSDP/UPnP через Интернет, основанные на уязвимом SDK Realtek.

Мы получили 198 уникальных отпечатков пальцев для устройств, ответивших по UPnP. Если мы оценим, что каждое устройство может быть продано тиражом 5 000 копий (в среднем), общее количество затронутых устройств приблизится к миллиону.

Список затронутых устройств, которые нам удалось идентифицировать, можно найти в приложении.

Системные индикаторы Realtek

Если вы оцениваете встроенное устройство, это признаки того, что система использует SDK Realtek.

Простым индикатором является файл /etc/motd, в котором упоминается rlx-linux:

Имя хоста обычно устанавливается как rlx-linux в сценарии инициализации:

Еще один — /etc/version , который присутствует не всегда:

rlx-linux — это урезанная система Linux от Realtek, созданная специально для чипсетов RTL.

Злоумышленники пытаются использовать CVE-2021-35395, группу уязвимостей в веб-интерфейсе Realtek SDK, для распространения вредоносного ПО Mirai на уязвимые устройства Интернета вещей.

Недавно обнаруженный недостаток

Неделю назад исследователи IoT Inspector опубликовали сведения о четырех уязвимостях с номерами CVE (CVE-2021-35392, CVE-2021-35393, CVE-2021-35394 и CVE-2021-35395), затрагивающих Realtek SDK, которые поставляется со специальной системой на кристалле (SoC) производства тайваньской полупроводниковой компании Realtek.

Произносимая SoC — набор микросхем Realtek RTL819xD — используется во многих встраиваемых устройствах в сфере Интернета вещей.

"Мы выявили по крайней мере 65 различных затронутых поставщиков с почти 200 уникальными отпечатками пальцев благодаря возможностям сканирования Shodan и некоторым неправильным настройкам поставщиков и производителей, которые предоставляют эти устройства для доступа в Интернет", — сообщили исследователи.

"Затронутые устройства реализуют возможности беспроводной связи и охватывают широкий спектр вариантов использования: от домашних шлюзов, туристических маршрутизаторов, повторителей Wi-Fi, IP-камер до интеллектуальных шлюзов Lightning и даже игрушек с подключением".

С тех пор Realtek исправила уязвимости, но производителям, использующим свои чипсеты, потребуется некоторое время для переноса и предоставления исправлений своим клиентам, и, вероятно, еще больше времени потребуется клиентам для внедрения предоставленных исправлений / обновлений безопасности.

CVE-2021-35395 попыток эксплуатации

Попытки эксплуатации CVE-2021-35395 были отмечены израильской компанией по обеспечению сетевой безопасности SAM Seamless Network, которая обнаружила их с помощью своего решения для домашней безопасности.

«В частности, мы заметили попытки взлома веб-страниц formWsc и formSysCmd. Эксплойт пытается развернуть вариант Mirai, обнаруженный в марте Palo Alto Networks», — поделился Омри Маллис, главный продукт компании Archited.

Он также отметил, что 6 августа компания Juniper Networks сообщила об аналогичном инциденте: компания обнаружила недавно обнаруженную уязвимость, затрагивающую маршрутизаторы на базе Arcadyan (CVE-2021–20090), которую начали эксплуатировать всего через два дня после публикации. целью злоумышленников было распространение того же варианта Mirai.

«Веб-сервер, обслуживающий ботнет Mirai, использует одну и ту же сетевую подсеть, что указывает на то, что в обоих инцидентах замешан один и тот же злоумышленник», — добавил Маллис.

«Эта цепочка событий показывает, что хакеры активно ищут уязвимости для внедрения команд и используют их для быстрого распространения широко распространенных вредоносных программ. Такие уязвимости легко использовать, и их можно быстро интегрировать в существующие хакерские платформы, которые используют злоумышленники, задолго до того, как устройства будут исправлены и поставщики средств защиты смогут отреагировать».

Исследователи SAM проанализировали анонимно собранные сетевые данные из более чем 2 миллионов домашних и корпоративных сетей и обнаружили, что удлинитель Wi-Fi от Netic и два маршрутизатора от Edimax и Repotec являются наиболее распространенными устройствами с Realtek SDK.< /p>

Пользователям устройств Интернета вещей следует проверить (неполный) список затронутых производителей и моделей устройств, чтобы узнать, уязвимы ли их устройства, а затем установить, не предоставили ли производители исправления. Если они этого не сделали, им следует призвать их сделать это как можно скорее.

Читайте также: