История, которую я сейчас расскажу, — классический пример современной охоты за уязвимостями. Пять человек, три месяца, 55 уязвимостей в сервисах Apple. И всё это не связано со взломом оборудования или iOS, а с веб-сервисами. Оказывается, даже у такого гиганта, как Apple, есть проблемы с безопасностью своих облачных сервисов.
Я изучил их отчет и выделил три наиболее интересных уязвимости. Среди них XSS в почтовом клиенте iCloud, позволяющая отправить червя всем контактам жертвы, SSRF, открывающая доступ к исходному коду iOS, и тривиальная (но не менее опасная) ошибка с паролем по умолчанию на закрытом форуме для учителей.
---
Как всё началось: разведка
Двадцатилетний Сэм Карри случайно обнаружил, что Apple платит не только за уязвимости оборудования и iOS, но и за уязвимости в веб-сервисах. Он собрал команду из четырех других исследователей, и они начали расследование.
Первое, что они осознали, — это масштаб. Apple владеет огромным диапазоном IP-адресов — 17.0.0.0/8. В него входят 25 000 веб-серверов, 10 000 в домене apple.com, еще 7 000 уникальных доменов и даже собственный домен верхнего уровня .apple. Они просканировали все, что могли, обнаружили массу интересных вещей (включая уязвимый VPN-сервер и утечку токенов в ошибках) и сосредоточились на наиболее перспективных целях.
--
Первая лунка. Форум для преподавателей: пароль, которым поделились все.
Что они атаковали: ade.apple.com — закрытый форум для выдающихся преподавателей Apple.
Суть в следующем: разработчики добавили на форум Jive собственный модуль авторизации Apple ID, но в коде формы регистрации по какой-то причине оставили скрытое поле для пароля с одинаковым значением для всех пользователей.
В анкете было написано:
<input id="password" type="hidden" value="##INvALID#%!3">
Исследователи предположили, что где-то в Jive существует способ войти в систему, используя имя пользователя и пароль, минуя Apple ID. Они нашли функцию cs_login, создали запрос и начали пробовать авторизацию. Это заняло всего минуту — три символа имени пользователя, один и тот же пароль.
Сервер ответил успешным ответом.
Они вошли в систему. Затем они нашли панель администратора (открытую по адресу /admin/; точка с запятой в конце очень помогает) и обнаружили учетную запись администратора с полными правами. С этими правами они могли выполнять код на сервере, получать доступ к внутренней сети Apple и управлять учетными записями пользователей.
---
Уязвимость 2. XSS в iCloud: как я могу украсть ваши фотографии и отправить червя всем вашим контактам.
Атака: почтовый сервис iCloud (icloud.com).
Суть в том, что Apple решила, что обработка электронных писем на стороне клиента — хорошая идея. Электронное письмо преобразуется в формат JSON, который затем обрабатывается JavaScript непосредственно в браузере.
Сэм Карри обнаружил, что если электронное письмо содержит два CSS-тега <style>, и у первого нет закрывающего тега, парсер объединяет их в один. Он отправил себе следующее письмо:
<style></style</style>
<style>le><sсript>alert(1)</sсript></style>
Когда он открыл электронное письмо, парсер объединил его в следующее:
<style></style><sscript>alert(1)</sscript></style>
Сработала тревога. Обнаружена XSS-атака на домене icloud.com.
Теперь злоумышленник может выполнять произвольный JavaScript-код от имени жертвы. Это означает, что он может запрашивать API iCloud, читать фотографии, документы, календари и списки контактов.
Карри написал концептуальный прототип, который:
1. Получает URL-адреса всех фотографий жертвы через API iCloud.
2. Вставляет их в электронное письмо.
3. Отправляет электронное письмо самому себе.
4. А затем — к списку контактов жертвы.
Технически, это почтовый червь. Он самовоспроизводится, крадет все данные из iCloud и распространяется дальше.
---
Третья лунка. SSRF в iCloud: доступ к исходному коду iOS.
Что подверглось атаке: тот же почтовый клиент iCloud, функция «Открыть в Pages».
Суть в том, что в iCloud можно открыть вложение в приложении «Страницы». При этом создается HTTP-запрос с параметром url, указывающим на файл. Исследователи попытались заменить этот URL произвольным, но сервер выдал ошибку.
Затем они добавили @ourdomain.com после разрешенного адреса. Например: https://[email protected].
Сервер интерпретировал p37-mailws.icloud.com как логин, а ourdomain.com как реальный адрес и отправил запрос туда.
И это еще не все. Оказалось, что любой файл, доступный серверу, можно прочитать. Исследователи написали скрипт, который обходил внутренние ресурсы Apple. Они обнаружили репозиторий Maven с исходным кодом приложений Apple, включая компоненты iOS.
Таким образом, уязвимость SSRF предоставила доступ к исходному коду операционной системы Apple.
---
Что ещё они обнаружили?
Помимо этих трех, команда обнаружила еще 52 уязвимости:
• Обход аутентификации на уровне глобального администратора.
• Внедрение команд из-за несанкционированного имени файла.
• Выполнение удаленного выполнения кода через забытый инструмент администратора.
· SQL-инъекция в Vertica.
• Скрытая XSS-атака во внутреннем портале поддержки.
• Выполнение PhantomJS на сервере, что позволило получить доступ к внутренним ресурсам и ключам AWS IAM.
--
Итог
Компания Apple устранила большинство уязвимостей в течение нескольких часов после сообщения об ошибке. Исследователям они заплатили 288 500 долларов.
Итог:
Даже у таких гигантов, как Apple, есть уязвимости.
• Веб-сервисы представляют собой не меньшую цель для атак, чем операционные системы. XSS-уязвимость в электронной почте — это не просто предупреждение; это потенциальный червь, который крадет все ваши данные.
SSRF — это доступ к внутренней сети и исходному коду.
Иногда, если у всех одинаковый пароль, достаточно простого подбора логинов методом перебора.
