Uhale під підозрою: фоторамки з Android заражаються через оновлення 4.2.0 і вступають до ботнетів

CyberSecureFox 🦊

Дослідники Quokka повідомили про критичні проблеми безпеки в цифрових фоторамках на платформі Uhale (екосистема ZEASN, нині Whale TV). Частина моделей після увімкнення автоматично отримує та виконує шкідливі компоненти, що перетворює побутові IoT-пристрої на інфраструктуру для ботнетів і подальших мережевих атак.

Як працює компрометація: шкідливе оновлення Uhale 4.2.0

За даними Quokka, під час першого запуску багато фоторамок з Android перевіряють оновлення додатка Uhale і встановлюють реліз версії 4.2.0, після чого пристрій перезавантажується. Оновлений застосунок ініціює завантаження корисного навантаження з віддалених серверів у Китаї та виконує його під час старту системи.

Шкідливий модуль у форматі JAR/DEX зберігається в каталозі Uhale і підхоплюється при кожному наступному завантаженні, забезпечуючи персистентність без участі користувача. Такий механізм нагадує класичні ланцюги OTA-компрометації, коли оновлення використовується як транспорт для впровадження коду.

Ознаки зв’язку з ботнетом Vo1d і малвар’ю Mzmess

Аналіз артефактів виявив перехресні індикатори, сумісні з ботнетом Vo1d і сімейством Mzmess: збіги префіксів пакетів, схожі рядки та назви класів, ідентичні мережеві ендпойнти та єдиний процес доставки й виконання модулів. Відомо, що Vo1d оперує мільйонами скомпрометованих IoT-пристроїв, що підвищує ризик масштабних DDoS-кампаній та зловживань проксі-функціоналом.

Компрометація ланцюга постачання чи модифікація збірки

Чому саме версія 4.2.0 стала тригером зараження, поки що незрозуміло. Можливі сценарії включають злам інфраструктури оновлень ZEASN/Whale TV або втручання на етапі складання прошивки. У травні 2025 року дослідники намагалися зв’язатися з виробником, однак, за їхніми словами, офіційної відповіді не отримали.

17 уразливостей, слабка криптографія та компоненти Adups

Окрім автоматичного завантаження малварі, Quokka описала 17 уразливостей, з яких 11 уже отримали CVE. Серед проблем — жорстко закодований AES-ключ для розшифрування відповідей sdkbin, використання слабких криптографічних патернів та інші hardcoded-ключі, що полегшують зловмисникам підробку або ретрансляцію даних.

На окремих моделях виявлено компоненти OTA-оновлень Adups і набір застарілих бібліотек. Подібні сторонні модулі та легасі-залежності традиційно погіршують контроль цілісності та перевірку підписів оновлень, збільшуючи ризик компрометації через ланцюг постачання.

Масштаб впливу та складність інвентаризації

Оціночна кількість уражених пристроїв невідома: фоторамки на Uhale продаються під різними брендами, а сама платформа згадується не завжди. Непрямі показники свідчать про значний охоп: застосунок Uhale у Google Play має понад 500 000 завантажень, в App Store — більш як 11 000 відгуків, а моделі на Amazon сумарно отримали близько 1000 відгуків. Такий white-label-підхід ускладнює інвентаризацію парку IoT і своєчасне реагування на інциденти.

Наслідки для користувачів і організацій

Заражені фоторамки можуть поповнювати ботнети для DDoS, використовуватись як проксі або брати участь у клікфроді. Хоча локально на пристрої зберігається небагато чутливих даних, доступ до домашньої чи офісної мережі створює ризик латерального переміщення і компрометації інших вузлів у периметрі.

Практичні кроки зниження ризику

Рекомендації включають: сегментацію IoT у окремі VLAN або гостьові SSID; обмеження вихідних підключень для виявлених фоторамок; за можливості вимкнення автооновлень і перевірку версії Uhale (уникати 4.2.0); моніторинг мережевого трафіку на аномалії; початкове налаштування офлайн. Організаціям варто впровадити контроль закупівель IoT, вимагати сертифікати безпеки, перевірку підписів OTA та підтримку офіційних збірок Android із Google Play Protect.

Історія з Uhale демонструє системний ризик ланцюга постачання в IoT: універсальні платформи, множинні бренди та непрозорі оновлення створюють умови для масштабних компрометацій. Користувачам варто провести інвентаризацію «розумних» пристроїв у мережі, посилити сегментацію і фільтрацію трафіку, а також відстежувати повідомлення Quokka та нові CVE. Тиск на вендорів із вимогою прозорих процесів оновлення та належної криптографічної дисципліни — практичний крок до зменшення подібних інцидентів.

Залишити коментар

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються дані ваших коментарів.