BlackPope
Местный
- Регистрация
- 27.04.2020
- Сообщения
- 242
- Реакции
- 35
Группа из пяти исследователей за три месяца напряженной работы сумела отыскать 55 уязвимостей в онлайн-сервисах корпорации Apple. Внимательно изучив опубликованную на их блоге информацию, мы решили подробно рассказать о трех наиболее интересных, на наш взгляд, находках хакеров.
ИБ-исследователи всегда уделяли немало внимания железу и операционным системам Apple, а вот громкие взломы облачных сервисов компании обычно сводились к краже чьих-то учетных данных. Но вот и этот бастион пал. Команда исследователей в виде двадцатилетнего Сэма Карри (Sam Curry), Бретта Бюрхауса (Brett Buerhaus), Бена Садегипура (Ben Sadeghipour), Сэмюэля Эрба (Samuel Erb) и Таннера Барнса (Tanner Barnes) опубликовала отчет об успешном обнаружении 55 дыр в веб-сервисах Apple. Продемонстрировав тем самым, насколько уязвимой может быть сетевая инфраструктура крупной компании, если ее безопасности не уделяется должного внимания.
Парни смогли выявить 11 критических уязвимостей, 29 — с высокой степенью потенциальной опасности, 13 — средней критичности и 2 — некритичных. Обнаруженные бреши позволяют злоумышленникам запустить червя, способного автоматически захватывать учетные записи iCloud, скомпрометировать ряд веб-приложений, предназначенных как для клиентов, так и для сотрудников Apple, а также получить доступ к святая святых — репозиторию, в котором хранятся исходные коды программ для iOS и macOS. Выявленные уязвимости также дают возможность перехватывать сеансы сотрудников компании, получив доступ к инструментам управления и прочей конфиденциальной информации.
На своем сайте Сэм Карри признается, что узнал обо всех аспектах программы Apple bug bounty случайно. Он прочитал в твиттере сообщение о том, что компания наградила призом в 100 тысяч долларов пользователя, нашедшего механизм обхода аутентификации учетной записи Apple. До этого Cэм думал, что корпорация платит только за обнаружение уязвимостей в железе и операционных системах.
Тот самый твит, вдохновивший Сэма Карри начать исследования
Изучив условия программы, Сэм решил попытать счастья. А чтобы работа двигалась быстрее, он написал несколькими хакерам, с которыми работал раньше, и предложил им принять участие в пентестинге. Так появилась команда, которая в итоге добилась успеха.
Для начала парни постарались собрать максимум информации обо всех доступных веб-сервисах Apple и их назначении. На специальной панели записывали сведения об IP-адресах, доменах, доступных портах, данных из HTTP-заголовков, ответов сервера и прочие полезные сведения.
Первый этап успешного взлома — сбор информации
Масштабы «сетевой империи» Apple поистине поражали воображение. Выяснилось, что корпорации принадлежит огромный диапазон IP-адресов 17.0.0.0/8, который включает 25 тысяч веб-серверов, 10 тысяч из которых находятся в доменной зоне apple.com, еще 7 тысяч уникальных доменов и в довершение всего,их собственный TLD .apple. Исследователи решили более детально изучить адреса в диапазоне 17.0.0.0/8, а также домены .apple.com и .icloud.com, поскольку именно там и были сосредоточены самые интересные функции.
Определившись с предметом для дальнейшего изучения, хакеры запустили автоматическое сканирование в поисках известных уязвимостей. Это позволило им лучше понять, как работает система аутентификации пользователей на сайтах Apple, как серверы обращаются с файлами cookies, какие там запущены веб-приложения и какие инструменты применялись для их разработки. В частности, были обнаружены серверы VPN с уязвимостью CVE-2020-3452, позволяющей читать локальные файлы, и утечка токена доступа в сообщении об ошибке на неработающей странице.
Результаты сканирования позволили исследователям сосредоточиться на нескольких веб-сервисах, представлявших наибольший интерес с точки зрения возможных уязвимостей. Самыми важными находками команды Сэм Карри поделился на своем сайте, а мы расскажем о них дальше.
Первым сайтом, который взломала команда Сэма Карри, был закрытый форум Apple Distinguished Educators (ADE), предназначенный для преподавателей, которые используют в работе технологии Apple. В качестве движка этого сервиса применяется Jive, к которому в Купертино прикрутили собственный модуль авторизации, позволяющий юзерам логиниться в систему с использованием своего Apple ID. Если пользователь еще не зарегистрирован в ADE, ему предлагают оставить заявку, заполнив нехитрую регистрационную форму.
Инвайт нужен не только на Лепру, но и на некоторые сайты Apple
При заполнении этой регистрационной формы пользователи вводят те же данные, которые обычно указывают при регистрации в Jive, но здесь программа пыталась сопоставить адрес email c учетной записью Apple ID. При этом регистрационная форма среди прочих данных передавала на сервер скрытое поле password со значением ###INvALID#%!3.
<div class="j-form-row">
<input id="password" type="hidden" value="###INvALID#%!3">
<div id="jive-pw-strength">
При каждой попытке регистрации пароль передавался один и тот же. В то же время в ADE можно авторизоваться только через Apple ID. Однако взломщики предположили, что существует какой-то способ войти в Jive с помощью имени одной из подтвержденных модераторами учетных записей и этого стандартного пароля из скрытого поля регистрационной формы. Вдумчивый гуглеж показал, что в Jive есть специальная функция cs_login, обеспечивающая вход в учетку стандартным методом — с логином и паролем юзера. Парни сформировали соответствующий HTTP-запрос для аутентификации в системе и получили от сервера сообщение о неправильном пароле, что, собственно, неудивительно, поскольку их учетки еще не прошли модерацию.
Чтобы найти действующие профили пользователей, Карри и компания воспользовались замечательным инструментом под названием Burp Suite. Спустя примерно две минуты перебора трехсимвольных имен пользователей в сочетании со стандартным паролем сервер вернул ответ об успешной авторизации.
Залогинившись в ADE, исследователи получили список администраторов форума, однако добыть доступ к панели администратора по стандартному адресу /admin/ у атакующих не вышло. После нескольких экспериментов исследователи выяснили, что админка открывается при добавлении к этому URL точки с запятой. Чтобы облегчить себе жизнь, хакеры прописали в Burp соответствующие правила для GET- и POST-запросов.
Правила для доступа к админке Jive в Burp
Тут выяснилась еще одна подробность: далеко не все юзеры, записанные в ADE в качестве администраторов, имеют полный доступ к административной панели Jive. Только попробовав несколько админских учеток, хакеры нашли такую, которая открывала доступ ко всем возможностям управления форумом — к установке плагинов, шаблонов, управлению файлами и выполнению кода.
Взломав учетку суперадминистратора, хакеры получили доступ к управлению ADE
С такими правами злоумышленники могли бы:
Что такое iCloud, владельцам девайсов Apple объяснять не надо — в этой облачной инфраструктуре хранятся и фотографии, и данные приложений, и резервные копии с пользовательских устройств. Кроме того, iCloud предоставляет пользователям доступ к функции Find my iPhone и к электронной почте. Учетка iCloud, как и другие «яблочные» сервисы, привязана к Apple ID.
Почта на iCloud — это полноценный почтовый сервис, такой же, как Gmail, с одним отличием: в почтовых клиентах на айфонах и маках iCloud используется в качестве электронной почты по умолчанию. Почтовый сервер размещается на домене icloud.com, так же как и другие сервисы iCloud, что теоретически делает их уязвимыми для межсайтового скриптинга (cross-site scripting). Сэму Карри и команде осталось только отыскать подходящую брешь в системе безопасности iCloud.
Исследователи обратили внимание на одну особенность работы почтовых приложений от Apple: когда пользователь получает и открывает электронное письмо, оно преобразуется в большой двоичный объект JSON, который обрабатывается с использованием JavaScript, а затем демонстрируется юзеру. Это означает, что обработка сообщений, в том числе анализ и очистка содержимого, выполняется не на стороне сервера, а на стороне клиента, при этом все функции визуализации самого письма реализованы с помощью JavaScript.
Экспериментируя с различными приемами XSS, Сэм Карри обнаружил, что если в письме встречается два CSS-тега <style>, то почтовая программа во время обработки собирала их содержимое в один тег. Если при этом разместить кусок закрывающего тега </sty в первом теге <style>, а вторую часть — le> — во втором, почтовый клиент продолжает думать, что тег все еще открыт, хотя это не так. Сэм создал и отправил самому себе письмо со следующим кодом:
<style></sty</style>
<style>le><sсript>alert(1)</sсript></style>
Когда он открыл это сообщение, то увидел, что уловка сработала!
Пример работы межсайтового скриптинга в iCloud
Почтовый клиент обработал и собрал этот фрагмент кода следующим образом:
<style></style><sсript>alert(1)</sсript></style>
Поскольку почтовый сервер располагается в домене icloud.com, это означает, что у приложения есть возможность получать HTTP-ответы для соответствующих API-интерфейсов службы iCloud. На практике это позволяет украсть у пользователей iCloud личную информацию вроде фотографий, сохраненных документов или данных календаря, а потом разослать этот эксплоит по всем контактам жертвы. Используемый для этого принцип XSS Сэм Карри показал на следующей схеме.
Принцип действия XSS в iCloud
Не откладывая дела в долгий ящик, парни запилили Proof of Concept, который с использованием iCloud API получает URL хранящихся в iCloud фотографий пользователя, вставляет их в теги изображений. Поскольку в почтовых клиентах от Apple используется JavaScript, злоумышленник может направить самому себе письмо, содержащее ссылки на видео, фото, документы жертвы, и ее список контактов, а затем разослать по этим контактам письмо с эксплоитом. Технически несложно написать скрипт, который автоматизирует этот процесс, в результате чего механизм распространения сплоита будет напоминать принцип действия почтового червя. PoC реализации этой уязвимости можно посмотреть на следующем видео.
Чуть позже Сэм Карри нашел еще одну XSS-уязвимость в «яблочном» почтовике, а именно в механизме обработки гиперссылок. Нередко интересные особенности поведения программ проявляются, когда немаркированный URL преобразуется в гиперссылку. Еще одно характерное место для поиска XSS-уязвимостей — удаление из кода письма определенных тегов вроде <iframe> и <script>. При этом парсеры часто игнорируют служебные символы вроде пробелов, переводов строк, символов табуляции, что открывает определенный простор для творчества.
Карри решил поиграть с обоими этими приемами и с удивлением обнаружил, что следующая строка ломает правильное поведение парсера JavaScript в почтовых клиентах Apple:
https://www.domain.com/abc#<script></script>https://domain.com/abc
После отправки сообщения с такой строкой оно обрабатывается парсером и получает следующее представление:
<a href="https://www.domain.com/abc#<a href=" https:="" www.domain.com="" abc=""" rel="noopener noreferrer">https://www.domain.com/abc</a>
Использовать этот эффект в недобрых целях не так-то просто, однако внутри тега <script> можно попытаться использовать различные атрибуты вроде src, onmouseover, onclick. Но злоумышленнику все равно придется использовать какой-то URL, чтобы парсер его правильно обработал и превратил в гиперссылку. После долгих экспериментов с различными спецсимволами, одинарными и двойными кавычками Сэм пришел к следующему формату полезной нагрузки:
https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert(document.domain)/.source;//
После обработки парсером строка преобразуется в следующий формат:
<a href="https://www.icloud.com/mail#<a href=" https:="" www.icloud.com="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//"">https://www.icloud.com/onmouseover=location=/javascript:alert(document.domain)/.source;//</a>
Если открыть такое письмо в почтовом клиенте Apple, мы можем увидеть вот такой симпатичный алерт.
Ошибка в обработке URL в почтовых клиентах Apple
Исследователи предложили следующее объяснение этому явлению: при обработке исходного URL теги <script></script> удалялись парсером, и на их месте образовался пробел, который ломал функцию автоматического преобразования URL в гиперссылку, не закрывая при этом тег <a href. Идущий следом URL вновь включал механизм преобразования адресов в ссылки — он добавлял в гиперссылку недостающие параметры (включая onmouseover), закрывал тег </a> и завершал обработчик события onmouseover. Теоретически эта уязвимость позволяет злоумышленникам выполнять произвольный код JavaScript в почтовом клиенте жертвы.
Одним из самых любопытных багов, найденных командой Сэма Карри, была уязвимость Server-Side Request Forgery (SSRF). Во время тестирования почтовика iCloud парни обнаружили, что пользователь может открывать определенные вложения в сообщения с помощью функции Open in Pages. При обработке формы этой функции создается специальный HTTP-запрос, содержащий параметр URL, в котором хранится адрес вложенного в сообщение файла. Если попытаться заменить этот адрес любым произвольным значением, сервер вернет ошибку 400 Bad Request. При обработке запроса создается задание, в котором ответ на HTTP-запрос преобразуется в документ Apple Pages, а затем открывается в новой вкладке.
Ответ на HTTP-запрос автоматически преобразуется в документ Apple Pages
При этом почтовик разрешает только URL-адреса из домена p37-mailws.icloud.com и не преобразовывает в документ Apple Pages страницы, если ответ сервера отличается от 200 OK. Во время преобразования выполняется несколько HTTP-запросов и формируется очередь заданий.
Во время преобразования выполняется несколько HTTP-запросов и формируется очередь заданий
Чтобы сломать этот механизм, достаточно добавить после разрешенного Apple адреса строку @ ourdomain.com, содержащую домен, на который будет перенаправляться запрос. В результате полученный HTML будет преобразован в документ Apple Pages и открыт в новой вкладке. Если запрашиваемый с сервера файл оказывался слишком большим, почтовая программа упаковывала его в Zip и любезно предлагала сохранить на диск.
Для автоматизации этого процесса Бретт Бюрхаус собрал специальный скрипт на Python. В результате исследователи получили доступ на чтение к внутреннему репозиторию Apple Maven, где хранятся исходники некоторых приложений Apple.
Хакеры получили доступ к репозиторию Apple Maven
Благодаря этой уязвимости злоумышленники могли:
Техническая схема атаки на получение доступа к репозиторию Apple Maven
Другие критические уязвимости, обнаруженные командой Карри:
Большая часть обнаруженных командой Сэма Карри уязвимостей была закрыта компанией Apple в течение нескольких часов после баг-репорта, а самой команде корпорация выплатила 55 100 долларов США, то есть примерно 250 долларов за одну уязвимость на человека. Правда, после поднятой в прессе шумихи Apple перечислила команде Карри в общей сложности 288 500 долларов, и сумма вознаграждения, вероятно, еще вырастет после подтверждения всех выявленных багов.
Сам Карри считает, что разработанная Apple программа Bug Bounty — это правильный шаг в выстраивании диалога с хакерами и серьезное подспорье в борьбе за безопасность «яблочных» сервисов. Полный отчет об обнаруженных уязвимостях опубликован на сайте Samcurry.net.
Вместе с тем в сетевой инфраструктуре Apple имеется значительное число критичных сервисов, таких как iCloud, Apple store и платформа для разработчиков. Это очень сложные программные комплексы, состоящие из множества веб-приложений, в которых наверняка остаются невыявленные уязвимости. Так что пентестерам и «белым шляпам» еще есть где развернуться.
ИБ-исследователи всегда уделяли немало внимания железу и операционным системам Apple, а вот громкие взломы облачных сервисов компании обычно сводились к краже чьих-то учетных данных. Но вот и этот бастион пал. Команда исследователей в виде двадцатилетнего Сэма Карри (Sam Curry), Бретта Бюрхауса (Brett Buerhaus), Бена Садегипура (Ben Sadeghipour), Сэмюэля Эрба (Samuel Erb) и Таннера Барнса (Tanner Barnes) опубликовала отчет об успешном обнаружении 55 дыр в веб-сервисах Apple. Продемонстрировав тем самым, насколько уязвимой может быть сетевая инфраструктура крупной компании, если ее безопасности не уделяется должного внимания.
Парни смогли выявить 11 критических уязвимостей, 29 — с высокой степенью потенциальной опасности, 13 — средней критичности и 2 — некритичных. Обнаруженные бреши позволяют злоумышленникам запустить червя, способного автоматически захватывать учетные записи iCloud, скомпрометировать ряд веб-приложений, предназначенных как для клиентов, так и для сотрудников Apple, а также получить доступ к святая святых — репозиторию, в котором хранятся исходные коды программ для iOS и macOS. Выявленные уязвимости также дают возможность перехватывать сеансы сотрудников компании, получив доступ к инструментам управления и прочей конфиденциальной информации.
На своем сайте Сэм Карри признается, что узнал обо всех аспектах программы Apple bug bounty случайно. Он прочитал в твиттере сообщение о том, что компания наградила призом в 100 тысяч долларов пользователя, нашедшего механизм обхода аутентификации учетной записи Apple. До этого Cэм думал, что корпорация платит только за обнаружение уязвимостей в железе и операционных системах.
Тот самый твит, вдохновивший Сэма Карри начать исследования
Изучив условия программы, Сэм решил попытать счастья. А чтобы работа двигалась быстрее, он написал несколькими хакерам, с которыми работал раньше, и предложил им принять участие в пентестинге. Так появилась команда, которая в итоге добилась успеха.
Рекогносцировка
Для начала парни постарались собрать максимум информации обо всех доступных веб-сервисах Apple и их назначении. На специальной панели записывали сведения об IP-адресах, доменах, доступных портах, данных из HTTP-заголовков, ответов сервера и прочие полезные сведения.
Первый этап успешного взлома — сбор информации
Масштабы «сетевой империи» Apple поистине поражали воображение. Выяснилось, что корпорации принадлежит огромный диапазон IP-адресов 17.0.0.0/8, который включает 25 тысяч веб-серверов, 10 тысяч из которых находятся в доменной зоне apple.com, еще 7 тысяч уникальных доменов и в довершение всего,их собственный TLD .apple. Исследователи решили более детально изучить адреса в диапазоне 17.0.0.0/8, а также домены .apple.com и .icloud.com, поскольку именно там и были сосредоточены самые интересные функции.
Определившись с предметом для дальнейшего изучения, хакеры запустили автоматическое сканирование в поисках известных уязвимостей. Это позволило им лучше понять, как работает система аутентификации пользователей на сайтах Apple, как серверы обращаются с файлами cookies, какие там запущены веб-приложения и какие инструменты применялись для их разработки. В частности, были обнаружены серверы VPN с уязвимостью CVE-2020-3452, позволяющей читать локальные файлы, и утечка токена доступа в сообщении об ошибке на неработающей странице.
Результаты сканирования позволили исследователям сосредоточиться на нескольких веб-сервисах, представлявших наибольший интерес с точки зрения возможных уязвимостей. Самыми важными находками команды Сэм Карри поделился на своем сайте, а мы расскажем о них дальше.
Компрометация учетных записей преподавателей Apple
Первым сайтом, который взломала команда Сэма Карри, был закрытый форум Apple Distinguished Educators (ADE), предназначенный для преподавателей, которые используют в работе технологии Apple. В качестве движка этого сервиса применяется Jive, к которому в Купертино прикрутили собственный модуль авторизации, позволяющий юзерам логиниться в систему с использованием своего Apple ID. Если пользователь еще не зарегистрирован в ADE, ему предлагают оставить заявку, заполнив нехитрую регистрационную форму.
Инвайт нужен не только на Лепру, но и на некоторые сайты Apple
При заполнении этой регистрационной формы пользователи вводят те же данные, которые обычно указывают при регистрации в Jive, но здесь программа пыталась сопоставить адрес email c учетной записью Apple ID. При этом регистрационная форма среди прочих данных передавала на сервер скрытое поле password со значением ###INvALID#%!3.
<div class="j-form-row">
<input id="password" type="hidden" value="###INvALID#%!3">
<div id="jive-pw-strength">
При каждой попытке регистрации пароль передавался один и тот же. В то же время в ADE можно авторизоваться только через Apple ID. Однако взломщики предположили, что существует какой-то способ войти в Jive с помощью имени одной из подтвержденных модераторами учетных записей и этого стандартного пароля из скрытого поля регистрационной формы. Вдумчивый гуглеж показал, что в Jive есть специальная функция cs_login, обеспечивающая вход в учетку стандартным методом — с логином и паролем юзера. Парни сформировали соответствующий HTTP-запрос для аутентификации в системе и получили от сервера сообщение о неправильном пароле, что, собственно, неудивительно, поскольку их учетки еще не прошли модерацию.
Чтобы найти действующие профили пользователей, Карри и компания воспользовались замечательным инструментом под названием Burp Suite. Спустя примерно две минуты перебора трехсимвольных имен пользователей в сочетании со стандартным паролем сервер вернул ответ об успешной авторизации.
Залогинившись в ADE, исследователи получили список администраторов форума, однако добыть доступ к панели администратора по стандартному адресу /admin/ у атакующих не вышло. После нескольких экспериментов исследователи выяснили, что админка открывается при добавлении к этому URL точки с запятой. Чтобы облегчить себе жизнь, хакеры прописали в Burp соответствующие правила для GET- и POST-запросов.
Правила для доступа к админке Jive в Burp
Тут выяснилась еще одна подробность: далеко не все юзеры, записанные в ADE в качестве администраторов, имеют полный доступ к административной панели Jive. Только попробовав несколько админских учеток, хакеры нашли такую, которая открывала доступ ко всем возможностям управления форумом — к установке плагинов, шаблонов, управлению файлами и выполнению кода.
Взломав учетку суперадминистратора, хакеры получили доступ к управлению ADE
С такими правами злоумышленники могли бы:
- выполнить произвольные команды на веб-сервере ade.apple.com;
- получить доступ к внутренней службе LDAP для управления учетными записями пользователей;
- получить доступ к части внутренней сети Apple.
Кража данных iCloud с использованием сетевого червя
Что такое iCloud, владельцам девайсов Apple объяснять не надо — в этой облачной инфраструктуре хранятся и фотографии, и данные приложений, и резервные копии с пользовательских устройств. Кроме того, iCloud предоставляет пользователям доступ к функции Find my iPhone и к электронной почте. Учетка iCloud, как и другие «яблочные» сервисы, привязана к Apple ID.
Почта на iCloud — это полноценный почтовый сервис, такой же, как Gmail, с одним отличием: в почтовых клиентах на айфонах и маках iCloud используется в качестве электронной почты по умолчанию. Почтовый сервер размещается на домене icloud.com, так же как и другие сервисы iCloud, что теоретически делает их уязвимыми для межсайтового скриптинга (cross-site scripting). Сэму Карри и команде осталось только отыскать подходящую брешь в системе безопасности iCloud.
Исследователи обратили внимание на одну особенность работы почтовых приложений от Apple: когда пользователь получает и открывает электронное письмо, оно преобразуется в большой двоичный объект JSON, который обрабатывается с использованием JavaScript, а затем демонстрируется юзеру. Это означает, что обработка сообщений, в том числе анализ и очистка содержимого, выполняется не на стороне сервера, а на стороне клиента, при этом все функции визуализации самого письма реализованы с помощью JavaScript.
Экспериментируя с различными приемами XSS, Сэм Карри обнаружил, что если в письме встречается два CSS-тега <style>, то почтовая программа во время обработки собирала их содержимое в один тег. Если при этом разместить кусок закрывающего тега </sty в первом теге <style>, а вторую часть — le> — во втором, почтовый клиент продолжает думать, что тег все еще открыт, хотя это не так. Сэм создал и отправил самому себе письмо со следующим кодом:
<style></sty</style>
<style>le><sсript>alert(1)</sсript></style>
Когда он открыл это сообщение, то увидел, что уловка сработала!
Пример работы межсайтового скриптинга в iCloud
Почтовый клиент обработал и собрал этот фрагмент кода следующим образом:
<style></style><sсript>alert(1)</sсript></style>
Поскольку почтовый сервер располагается в домене icloud.com, это означает, что у приложения есть возможность получать HTTP-ответы для соответствующих API-интерфейсов службы iCloud. На практике это позволяет украсть у пользователей iCloud личную информацию вроде фотографий, сохраненных документов или данных календаря, а потом разослать этот эксплоит по всем контактам жертвы. Используемый для этого принцип XSS Сэм Карри показал на следующей схеме.
Принцип действия XSS в iCloud
Не откладывая дела в долгий ящик, парни запилили Proof of Concept, который с использованием iCloud API получает URL хранящихся в iCloud фотографий пользователя, вставляет их в теги изображений. Поскольку в почтовых клиентах от Apple используется JavaScript, злоумышленник может направить самому себе письмо, содержащее ссылки на видео, фото, документы жертвы, и ее список контактов, а затем разослать по этим контактам письмо с эксплоитом. Технически несложно написать скрипт, который автоматизирует этот процесс, в результате чего механизм распространения сплоита будет напоминать принцип действия почтового червя. PoC реализации этой уязвимости можно посмотреть на следующем видео.
Чуть позже Сэм Карри нашел еще одну XSS-уязвимость в «яблочном» почтовике, а именно в механизме обработки гиперссылок. Нередко интересные особенности поведения программ проявляются, когда немаркированный URL преобразуется в гиперссылку. Еще одно характерное место для поиска XSS-уязвимостей — удаление из кода письма определенных тегов вроде <iframe> и <script>. При этом парсеры часто игнорируют служебные символы вроде пробелов, переводов строк, символов табуляции, что открывает определенный простор для творчества.
Карри решил поиграть с обоими этими приемами и с удивлением обнаружил, что следующая строка ломает правильное поведение парсера JavaScript в почтовых клиентах Apple:
https://www.domain.com/abc#<script></script>https://domain.com/abc
После отправки сообщения с такой строкой оно обрабатывается парсером и получает следующее представление:
<a href="https://www.domain.com/abc#<a href=" https:="" www.domain.com="" abc=""" rel="noopener noreferrer">https://www.domain.com/abc</a>
Использовать этот эффект в недобрых целях не так-то просто, однако внутри тега <script> можно попытаться использовать различные атрибуты вроде src, onmouseover, onclick. Но злоумышленнику все равно придется использовать какой-то URL, чтобы парсер его правильно обработал и превратил в гиперссылку. После долгих экспериментов с различными спецсимволами, одинарными и двойными кавычками Сэм пришел к следующему формату полезной нагрузки:
https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert(document.domain)/.source;//
После обработки парсером строка преобразуется в следующий формат:
<a href="https://www.icloud.com/mail#<a href=" https:="" www.icloud.com="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//"">https://www.icloud.com/onmouseover=location=/javascript:alert(document.domain)/.source;//</a>
Если открыть такое письмо в почтовом клиенте Apple, мы можем увидеть вот такой симпатичный алерт.
Ошибка в обработке URL в почтовых клиентах Apple
Исследователи предложили следующее объяснение этому явлению: при обработке исходного URL теги <script></script> удалялись парсером, и на их месте образовался пробел, который ломал функцию автоматического преобразования URL в гиперссылку, не закрывая при этом тег <a href. Идущий следом URL вновь включал механизм преобразования адресов в ссылки — он добавлял в гиперссылку недостающие параметры (включая onmouseover), закрывал тег </a> и завершал обработчик события onmouseover. Теоретически эта уязвимость позволяет злоумышленникам выполнять произвольный код JavaScript в почтовом клиенте жертвы.
Доступ к репозиторию с исходниками
Одним из самых любопытных багов, найденных командой Сэма Карри, была уязвимость Server-Side Request Forgery (SSRF). Во время тестирования почтовика iCloud парни обнаружили, что пользователь может открывать определенные вложения в сообщения с помощью функции Open in Pages. При обработке формы этой функции создается специальный HTTP-запрос, содержащий параметр URL, в котором хранится адрес вложенного в сообщение файла. Если попытаться заменить этот адрес любым произвольным значением, сервер вернет ошибку 400 Bad Request. При обработке запроса создается задание, в котором ответ на HTTP-запрос преобразуется в документ Apple Pages, а затем открывается в новой вкладке.
Ответ на HTTP-запрос автоматически преобразуется в документ Apple Pages
При этом почтовик разрешает только URL-адреса из домена p37-mailws.icloud.com и не преобразовывает в документ Apple Pages страницы, если ответ сервера отличается от 200 OK. Во время преобразования выполняется несколько HTTP-запросов и формируется очередь заданий.
Во время преобразования выполняется несколько HTTP-запросов и формируется очередь заданий
Чтобы сломать этот механизм, достаточно добавить после разрешенного Apple адреса строку @ ourdomain.com, содержащую домен, на который будет перенаправляться запрос. В результате полученный HTML будет преобразован в документ Apple Pages и открыт в новой вкладке. Если запрашиваемый с сервера файл оказывался слишком большим, почтовая программа упаковывала его в Zip и любезно предлагала сохранить на диск.
Для автоматизации этого процесса Бретт Бюрхаус собрал специальный скрипт на Python. В результате исследователи получили доступ на чтение к внутреннему репозиторию Apple Maven, где хранятся исходники некоторых приложений Apple.
Хакеры получили доступ к репозиторию Apple Maven
Благодаря этой уязвимости злоумышленники могли:
- получить доступ к исходникам iOS в репозитории Мaven;
- получить доступ ко всему содержимому внутренней сети Apple;
- полностью скомпрометировать сеанс жертвы с помощью уязвимости межсайтового скриптинга из-за общедоступных файлов cookie в HTTP-запросе.
Техническая схема атаки на получение доступа к репозиторию Apple Maven
Еще больше дыр
Другие критические уязвимости, обнаруженные командой Карри:
- обход аутентификации с помощью неправильно настроенных разрешений обеспечивает атакующему доступ глобального администратора;
- инъекции команд через некорректно очищенный аргумент имени файла;
- удаленное выполнение произвольного кода через утечку секрета и оставленного открытым инструмента для администраторов;
- утечка памяти, приводящая к компрометации учетных записей сотрудников и пользователей, а также открывающая доступ к различным внутренним приложениям;
- SQL-инъекции Vertica через некорректную очистку ввода;
- слепая XSS, позволяющая получить доступ к внутреннему порталу поддержки для отслеживания проблем клиентов и сотрудников;
- выполнение PhantomJS на стороне сервера, позволяющее получить доступ к внутренним ресурсам и ключам AWS IAM.
Итоги
Большая часть обнаруженных командой Сэма Карри уязвимостей была закрыта компанией Apple в течение нескольких часов после баг-репорта, а самой команде корпорация выплатила 55 100 долларов США, то есть примерно 250 долларов за одну уязвимость на человека. Правда, после поднятой в прессе шумихи Apple перечислила команде Карри в общей сложности 288 500 долларов, и сумма вознаграждения, вероятно, еще вырастет после подтверждения всех выявленных багов.
Сам Карри считает, что разработанная Apple программа Bug Bounty — это правильный шаг в выстраивании диалога с хакерами и серьезное подспорье в борьбе за безопасность «яблочных» сервисов. Полный отчет об обнаруженных уязвимостях опубликован на сайте Samcurry.net.
Вместе с тем в сетевой инфраструктуре Apple имеется значительное число критичных сервисов, таких как iCloud, Apple store и платформа для разработчиков. Это очень сложные программные комплексы, состоящие из множества веб-приложений, в которых наверняка остаются невыявленные уязвимости. Так что пентестерам и «белым шляпам» еще есть где развернуться.