Лист міг показувати чужу адресу icloud.com і водночас успішно проходити перевірки автентифікації пошти. У технічному звіті від 1 жовтня дослідник SEC Consult Тімо Лонгін пояснив, як дві помилки обробки повідомлень в iCloud зробили це можливим. Дієвість виправлень Apple підтвердили 9 грудня 2025 року: новина стосується оприлюдненого дослідження, а не досі відкритого обходу захисту. [1]
Це важлива відмінність, коли несподіваний лист просить довіритися відправнику. Успішна автентифікація дає корисні відомості про доставлення пошти, але не робить інструкції в листі надійними. Цей випадок показує, як постачальник міг схвалити одне представлення повідомлення, а надіслати інше.
Пряму підміну блокували; інше прочитання спрацювало
Зазвичай iCloud відхиляв повідомлення, якщо видима адреса From не належала обліковому запису, з якого виконали вхід. Просто вписати адресу іншої людини було недостатньо. Натомість Лонгін дослідив етапи обробки між прийманням листа й доставленням.
У першому способі незвичні символи повернення каретки змушували два парсери — компоненти, що читають структуру повідомлення, — по-різному розуміти рядок відправника. Початкова перевірка брала правильну адресу облікового запису. Подальша нормалізація перетворювала інший рядок на розпізнаваний заголовок From. Дослідник використав ту саму розбіжність, щоб перемістити справжній заголовок відправника в тіло листа, залишивши одержувачу підставлену адресу.
Схема показує ключову межу: перевірка права відправляти лист і підготовка до доставлення неоднаково тлумачили ті самі байти. Поштовий сервіс одержувача часто відхиляє два заголовки відправника. Зміна місця, де закінчувалася секція заголовків, дала змогу обійти цю перешкоду в продемонстрованому способі. Для такої підміни не був потрібний доступ до скриньки людини, від імені якої надсилали лист.
Чому SPF, DKIM і DMARC не викрили підміну
SPF перевіряє, чи має сервер право надсилати пошту для домену адреси в транспортному конверті. DKIM перевіряє підпис домену над визначеним вмістом повідомлення. DMARC перевіряє узгодженість видимого домену відправника з доменом, автентифікованим через SPF або DKIM. Це перевірки рівня домену, а не універсальна гарантія, що лист дозволила надіслати саме людина чи скринька, показана в рядку відправника. Окреме повідомлення CERT/CC про неоднозначне тлумачення From пояснює, як розбіжності між сервісами та клієнтами підривають це припущення. [2]
У демонстрації iCloud підпис додавався після роботи другого парсера. Отже, DKIM міг підтвердити саме доставлену версію, хоча попередня перевірка права відправника бачила іншу структуру. SPF і DMARC також проходили. Помилка виникала до підписування, а не через зламану перевірку підпису.
Панель автентифікації — результат дослідницького тесту, а не повідомлення про викрадений обліковий запис жертви. Вона ілюструє конкретний висновок: справжня інфраструктура й чинний підпис можуть поєднуватися з підставленою адресою скриньки, якщо система надсилання схвалює неправильне представлення листа.
Другий спосіб пережив перше виправлення
Коли початковий спосіб перестав працювати, Лонгін знайшов іншу розбіжність — у правилах SMTP щодо крапок на початку рядка, відомих як dot-stuffing. Один етап обробки розумів їх інакше, ніж наступний. Видалення початкової крапки могло відкрити заголовок відправника, який попередня перевірка не розпізнавала. Пов’язана розбіжність знову виводила справжній рядок відправника із секції заголовків.
Хронологія розкриття описує повторні перевірки часткових виправлень до підтвердження усунення проблеми в грудні 2025 року. Інженерний урок конкретний: перевірки відправника перед перетворенням листа недостатньо, якщо це перетворення змінює адресу, яку розпізнають наступні компоненти. Ці демонстрації не встановлюють активної фішингової кампанії, кількості жертв чи викрадення облікових записів.
Що насправді означає несподіваний лист iCloud
Лист від нібито вашої або знайомої адреси сам собою не доводить, що до відповідного облікового запису отримали доступ. Підміна відправника й захоплення облікового запису — різні питання. Схожий принцип незалежної перевірки повідомлення застосовується до фішингових листів від імені менеджерів паролів і фальшивих повідомлень про списання Apple Pay.
Якщо лист несподівано просить оплату, пароль або підтвердження, відкрийте потрібний застосунок чи відомий сайт самостійно, без посилання або телефонного номера з повідомлення. Apple радить нікому не передавати паролі й коди перевірки та пересилати підозрілі листи від нібито Apple на reportphishing [at] apple [dot] com. [3]
Адміністраторам пошти варто зберегти оригінал повідомлення й зіставити видимий From, адресу в транспортному конверті та результати автентифікації. Невідповідність є підставою для розслідування, а не автоматичним вироком: законне пересилання та інші поштові схеми також можуть створювати відмінності. Описане дослідження не вимагає від читача спеціального способу обходу проблеми після виправлень iCloud.
Висновок простий і конкретний: перевірки автентифікації залишаються корисними, але незвичний запит слід підтвердити через канал, якому ви вже довіряєте.
Джерела
- Тімо Лонгін / SEC Consult Vulnerability Lab. «From: [email protected] — підміна довільних адрес Apple iCloud». 1 жовтня 2026 року. Дослідження й хронологія розкриття.
- CERT/CC. «Автентифіковані користувачі SMTP можуть підмінювати інші адреси через неоднозначне тлумачення From». VU#517845, перевірено 3 жовтня 2026 року. Повідомлення про тлумачення відправника.
- Apple Support. «Як розпізнати й уникнути соціальної інженерії, фішингових повідомлень, фальшивих дзвінків підтримки та інших шахрайств». Перевірено 3 жовтня 2026 року. Офіційні поради щодо повідомлення про шахрайство й захисту облікового запису.
