Apple security manager что это

Application Security Manager. Разработчик или безопасник?

Большинство успешных атак организации реализуется через уязвимости и закладки в софте. К счастью, сканер уязвимостей ПО уже рассматривается компаниями не как что-то экзотическое, а как необходимый элемент инфраструктуры защиты. Если при небольших объемах разработки можно использовать сканер as is, то когда объемы большие, приходится автоматизировать процесс. Но кто должен им управлять? Решать, как часто проверять релизы? Заниматься верификацией уязвимостей? Принимать решение, наложить ли вето на релиз и отправить код на устранение уязвимостей? И отвечать на многие другие вопросы. Вот тут на авансцену выходит Application Security Manager — менеджер по безопасной разработке ПО.

Но где сыскать такую редкую птицу или как вырастить самим? Артем Бычков, менеджер по безопасности приложений АО «Райффайзенбанк», и Даниил Чернов, руководитель направления Solar appScreener компании «Ростелеком-Солар», рассказывают, какие требования к Application Security Manager диктует практика разработки в российских компаниях.

Кто такой Аппликейшн Секьюрити Менеджер

Организации рано или поздно приходят к осознанию необходимости найма такого человека в команду. В частности, потому что никто из имеющихся в компании специалистов на эту роль напрямую не подходит. Разработчики? Их опыт работы связан именно с разработкой софта – транслировать найденные уязвимости в риски ИБ, а тем более риски для бизнеса для них весьма затруднительно. Безопасники? Для них проблематично погружение в тонкости разработки: для верификации уязвимостей необходимо умение разбираться в программных кодах на разных языках, что требует наличия серьезного опыта разработки.

Давайте рассмотрим, какие задачи возникают в ходе реализации процесса безопасной разработки, которые предстоит решать Аппликейшн Секьюрити Менеджеру (АСМ).

У читателя может сложиться мнение, что работа АСМ связана исключительно с проведением проверок программных разработок на предмет соответствия требованиям безопасности. Но вопросы безопасности возникают на различных этапах жизненного цикла системы, начиная от проектирования и заканчивая развертыванием на продуктив. Существуют различные модели построения цикла безопасной разработки (Software Security Touchpoints, SDLC и другие) и разные методики встраивания этих практик в процесс (в зависимости от применяемого подхода – waterfall, agile). Но все они сходятся в ключевых моментах: о безопасности нужно думать на всех этапах жизненного цикла системы.

Очевидно, что в рамках более-менее крупного проекта один человек вряд ли сможет выполнить работы на всех этапах. Редко кто в одиночку способен разработать требования к безопасности приложения, выполнить ревью его архитектуры и проверить результат работы аналитиков, провести аудит безопасности кода, убедиться, что во время тестирования были проведены необходимые тесты защищенности приложения и что система была безопасно развернута и правильно сконфигурирована. Более того, часто эти активности выполняются представителями разных команд и подразделений. Чтобы весь механизм работал, как нужно, движущей силой процесса должен стать АСМ. Задача АСМ – обеспечить выполнение практик безопасной разработки, либо своими силами, либо делегируя определенные задачи профильным специалистам. Однако, исходя из нашей практики, просто раздать задачи ответственным и почивать на лаврах у АСМ не получится.

Какие требования предъявляются к АСМ

Во-первых, от него требуется понимание проекта, который он сопровождает. Это особенно важно в agile-разработке, когда, в отличие от ватерфольной модели, у тебя нет 2-х месяцев на то, чтобы провести ревью перед релизом. От АСМ зависит, например, как сформированные на этапе проектирования требования будут интерпретированы командой, как лягут на архитектуру, являются ли они вообще реализуемыми и не создадут ли серьезных технических проблем в будущем. Чаще всего АСМ является основным потребителем, интерпретатором и оценщиком отчетов автоматизированных инструментов и аудитов, сделанных третьими сторонами. Именно АСМ отфильтровывает нерелевантные и ошибочные результаты, оценивает риски, участвует в процессах управления исключениями и выработки компенсирующих мер.

Приведем пример из жизни: аудит или сканер исходного кода выявил в проекте использование небезопасной хеш-функции (MD5). Политика компании формально настаивает на том, что использовать ее нельзя, и вендор согласен заменить функцию на более безопасную за 3 месяца и крупную сумму. Нюанс состоял в том, что в данном случае неустойчивость хеш-функции к коллизиям никак не влияла на безопасность системы, так как функция не использовалась для защиты целостности. Формальный подход в данном случае и замена одной функции другой привел к необоснованному затягиванию сроков вывода проекта в продуктив и значительным затратам, дав нулевой выигрыш в безопасности.

Во-вторых, в дополнение к первому, АСМ должен обладать знаниями из различных областей: нужно понимать процессы разработки и принципы информационной безопасности. Важны в том числе и «хард-скилы», ведь очень тяжело критически оценивать результаты работы профильных специалистов и автоматизированных инструментов, если не можешь прочитать код, не понимаешь возможных путей эксплуатации уязвимостей. Наверняка многие сталкивались с ситуацией, когда в отчете по анализу кода или пентесту фигурирует критическая уязвимость, но разработчики не согласны с этим (при этом они, как правило, тоже хотят создать безопасную систему) и указывают на то, что аудиторы не смогли провести эксплуатацию данной уязвимости. Как оценить, кто прав в подобной ситуации? Без технических навыков объективно разрешить спор будет сложно. Если процесс разработки безопасного ПО строится руками внешней организации и/или по сервисной модели – кто и как будет оценивать работоспособность «технических» практик?

Еще один жизненный пример: внедряется новый инструмент разработки, его работоспособность проверяется на референсном проекте, после чего он передается в промышленную эксплуатацию. К нему постепенно подключаются проекты, отрисовывается красивый зеленый дашборд… и тут происходит ИБ-инцидент. Как выясняется, использованная «дыра» должна была быть обнаружена еще на этапе динамического анализа. Но этого не произошло, потому что… никто не посмотрел, а как работает этот топовый сканер уязвимостей, обычно выдающий прекрасные результаты, с SPA-приложениями на новом JavaScript-фреймворке. Оказалось, что он не может «увидеть» динамически генерируемую форму аутентификации и сделать нужные проверки. И никто не обращал на это внимание, поскольку все работало. У разработчиков не было потребности вникать в специфику функционирования сканеров, чтобы обратить на это внимание, а безопасники не видели критических отличий между разными подходами к веб-разработке.

Где взять такого специалиста

Кто изучал рынок, тот наверняка столкнулся с острым дефицитом специалистов по безопасности приложений. Как правило сценарий выглядит следующим образом: внутренние заказчики составляют требования к кандидату и передают их в кадры. Если требования жёсткие, то по результатам свободного поиска на выходе компания получает ноль кандидатов, так как готовые специалисты крайне редко вывешивают резюме в открытый доступ. Если они и меняют работу, то это чаще всего происходит легко и непринужденно через имеющиеся контакты. Как быть?

Можно попытаться переманить профессионала из других компаний, но этот путь по разным причинам не всегда приемлем. Все чаще на рынке появляются конкурсы на аутстаффинг АСМ, что вполне успешно позволяет закрыть вопрос за счет аренды экспертов у сервис-провайдера.

Но есть и другой вариант. Можно попытаться вырастить своего профессионала. В качестве кандидатов на подобную роль могут подойти представители двух направлений:

1. выходцы из разработки, увлекающиеся или желающие развиваться в сфере безопасности;
2. безопасники-технари, знакомые с разработкой и безопасностью ПО и желающие глубже погрузиться в эту тематику.

И тем, и другим кандидатам понадобится овладеть недостающим пакетом знаний. При этом желающие «перековаться» выходцы из разработки будут обладать лучшим пониманием сложившейся культуры и процессов в знакомых им командах. У них может уйти довольно много времени на освоение областей знаний, связанных с информационной безопасностью. Однако опыт показывает, что среди разработчиков, тестировщиков, аналитиков и архитекторов можно найти интересующихся безопасностью людей, уже обладающих определенным набором знаний в сфере безопасности приложений. Они могут стать идеальными кандидатами на вакансию АСМ.

Профессиональным же безопасникам придется акклиматизироваться, меняя сложившиеся привычные подходы к организации работы и перенимая культуру в командах, занимающихся разработкой. Однако, если специалист по безопасности пишет код и знаком с процессами разработки, то в команду он вольется быстро и просто.

Источник

Apple Platform Security

Hardware security

Secure software requires a foundation of security built into hardware. That’s why Apple devices—running iOS, iPadOS, macOS, tvOS, or watchOS—have security capabilities designed into silicon.

System security

Building on the unique capabilities of Apple hardware, system security is designed to maximize the security of the operating systems on Apple devices without compromising usability. System security encompasses the startup process, software updates, and the ongoing operation of the operating system.

Encryption and Data Protection

Apple devices have encryption features to safeguard user data and enable remote wipe in the case of device theft or loss.

App security

Apple provides layers of protection designed to ensure that apps are free of known malware and haven’t been tampered with. Other protections help ensure that access from apps to user data is carefully mediated.

Services security

Apple has built a robust set of services to help users get even more utility and productivity out of their devices. These services include Apple ID , iCloud, Sign in with Apple , Apple Pay , iMessage, FaceTime, and Find My .

To browse Apple Platform Security, click Table of Contents at the top of the page. To download a PDF, click or tap here.

Источник

Обзор безопасности системы

Механизм обеспечения безопасности системы, который основывается на уникальных возможностях устройств Apple, отвечает за контроль доступа к ресурсам системы на устройствах Apple без ущерба для удобства пользователей. Механизм обеспечения безопасности системы объединяет в себе процесс загрузки, обновление программного обеспечения и защиту вычислительных ресурсов системы, таких как процессор, память, диск, программное обеспечение и сохраненные данные.

Самые новые версии операционных систем Apple являются самыми безопасными. Важным компонентом безопасности Apple является безопасная загрузка, которая защищает систему от заражения вредоносным программным обеспечением во время загрузки. В основе безопасной загрузки лежит аппаратное обеспечение, с которого начинается цепочка доверия, объединяющая все модули программного обеспечения. Каждый шаг направлен на то, чтобы звено убеждалось в том, что следующее звено функционирует должным образом, прежде чем передать ему управление. Эта модель безопасности поддерживает не только стандартную загрузку устройств Apple, но и различные режимы восстановления и своевременного обновления на устройствах Apple. Такие подкомпоненты, как чип T2 и сопроцессор Secure Enclave, также выполняют собственную безопасную загрузку. Это помогает гарантировать, что они загружают только заведомо безопасный код Apple. Система обновления также может помогать предотвращать атаки через понижение версии, чтобы злоумышленник не мог установить на устройстве предыдущую версию операционной системы (которую он умеет взламывать) для кражи пользовательских данных.

Устройства Apple также оснащены средствами защиты на этапах загрузки и выполнения, которые обеспечивают их целостность в процессе текущей работы. Чипы Apple в iPhone, iPad, Apple Watch , Apple TV , HomePod и компьютерах Mac с чипом Apple формируют общую архитектуру для защиты целостности операционной системы. Кроме того, в macOS имеется расширенный настраиваемый набор функций защиты для поддержки своей отличающейся вычислительной модели, а также возможностей, поддерживаемых на всех аппаратных платформах Mac.

Источник

Почему я отказался от 18 тысяч долларов по баунти-программе Apple

Эта статья посвящена тому, как я обнаружил уязвимость в конечной точке восстановления пароля Apple, которая позволила мне захватить аккаунт iCloud. Уязвимость полностью пропатчена отделом безопасности Apple и больше не работает. В рамках баунти-программы Apple Security Team вознаградила меня 18 тысячами долларов, но я отказался их получать. В статье я расскажу о том, почему отказался от вознаграждения.

После обнаружения уязвимости захвата аккаунта Instagram я осознал, что многие другие сервисы подвержены брутфорсу на основе условий гонки. Поэтому я продолжил сообщать о подобных проблемах других поставщиков услуг, подверженных уязвимости, например Microsoft, Apple и некоторых других.

Многие люди путают эту уязвимость с обычной атакой брутфорсом, но это не так. В ней мы отправляем множество параллельных запросов серверу, чтобы воспользоваться уязвимостью условий гонки, присутствующей в ограничениях частоты запросов, позволяющих обойти защиту.

Теперь я расскажу о том, что обнаружил у Apple.

Опция забытого пароля Apple ID позволяет пользователям менять пароль при помощи 6-символьного цифрового OTP, отправленного на номер мобильного телефона или адрес электронной почты. После ввода правильного OTP пользователь может изменить пароль.

Страница забытого пароля Apple предлагает после ввода адреса электронной почты ввести номер мобильного телефона

Из соображений безопасности Apple для запроса OTP предлагает ввести доверенный телефонный номер вместе с адресом электронной почты.

То есть для эксплуатации этой уязвимости нам нужно знать доверенный телефонный номер, а также адрес электронной почты, чтобы запросить OTP, после чего мы можем попробовать перебрать все варианты кода из шести цифр, что потребует примерно 1 миллион попыток (10 ^ 6).

При тестировании выяснилось, что конечная точка восстановления пароля имеет довольно строгие ограничения частоты запросов. Если ввести больше 5 попыток, то аккаунт на следующие несколько часов будет заблокирован, и не поможет даже смена IP-адреса.

POST-запрос HTTP, отправленный конечной точке восстановления пароля, и её ответ

Затем я попробовал использовать брутфорс созданием условий гонки, отправляя одновременные POST-запросы серверу Apple, и обнаружил другие ограничения.

К моему удивлению, у Apple есть ограничения на частоту параллельных POST-запросов с одного IP-адреса, не только в конечной точке восстановления пароля, но и у всего сервера. Мы не можем отправить больше шести параллельных POST-запросов, они будут пропущены. При этом наш IP-адрес будет занесён в чёрный список для будущих POST-запросов с ошибкой 503.

Поэтому я решил, что сервер неуязвим к подобному типу атак, но у меня ещё оставалась надежда, так как это общие ограничения частоты запросов для всего сервера, не относящиеся конкретно к конечной точке проверки кода.

Проведя тестирование, я выяснил следующее:

1. iforgot.apple.com резолвится в 6 IP-адресов по всему миру (17.141.5.112, 17.32.194.36, 17.151.240.33, 17.151.240.1, 17.32.194.5, 17.111.105.243).
2. Существует два ограничения на частоту запросов, о которых мы уже говорили, одно срабатывает, если мы отправим больше 5 запросов конечной точке восстановления пароля (http://iforgot.apple.com/password/verify/smscode), второе относится к серверу Apple и срабатывает, когда мы отправляем больше 6 параллельных POST-запросов.
3. Оба эти ограничения на частоту связаны с IP-адресом конкретного сервера Apple, то есть мы всё равно можем отправлять запросы (хоть и в пределах ограничений) на другой IP-адрес сервера Apple.
4. Мы можем отправлять до 6 параллельных запросов IP-адресу сервера Apple (привязав iforgot.apple.com к IP-адресу) с одного клиентского IP-адреса в соответствии с их ограничениями. Как сказано выше, резолвится 6 IP-адресов Apple. То есть с одного IP-адреса мы можем отправлять до 36 запросов на 6 IP-адресов Apple (6 x 6 = 36).
5. Следовательно, атакующему потребуется 28 тысяч IP-адресов для отправки до 1 миллиона запросов для успешной верификации кода из 6 цифр.

Кажется, что можно легко получить 28 тысяч IP-адресов при помощи поставщиков облачных сервисов, но здесь начинается самое сложное — сервер Apple демонстрирует странное поведение, когда мы пытаемся отправлять POST-запросы с поставщиков облачных услуг наподобие AWS, Google Cloud и т.п.

Ответ на любой POST-запрос от AWS и Google Cloud

Серверы отклоняют POST-запрос с ошибкой 502 Bad gateway, даже не проверяя URI и тело запроса. Я попробовал менять IP, но все они возвращали один и тот же код ответа, то есть сервер занёс в чёрный список все ASN каких-то поставщиков облачных сервисов, если я понял правильно.

Это усложняет атаку для тех, кто использует только облачные сервисы с хорошей репутацией, например AWS. Я попробовал разных поставщиков и наконец нашёл несколько провайдеров, IP-адреса в сетях которых не занесены в чёрный список.

Затем я попытался отправлять множество параллельных POST-запросов с разных IP-адресов, чтобы проверить возможность обхода защиты.

Сработало! Теперь я могу менять пароль любого Apple ID при помощи только доверенного телефонного номера.

Разумеется, эту атаку непросто провести, для успешной эксплуатации уязвимости требуется соответствующая система. Сначала нам нужно обойти SMS с кодом из 6 цифр, после код из 6 цифр, полученный на адрес электронной почты. Оба обхода основаны на одной методике и используют одну среду, поэтому нам не нужно ничего менять, пытаясь выполнить второй обход защиты. Даже если у пользователя включена двухфакторная аутентификация, мы всё равно сможем получить доступ к его аккаунту, потому что конечная точка 2FA имеет такое же ограничение по частоте и уязвима. Та же уязвимость присутствует и в конечной точке подтверждения пароля.

1 июля 2020 года я передал эту информацию с подробным описанием воссоздания эксплойта и видео отделу безопасности. Отдел безопасности Apple подтвердил и признал проблему спустя несколько минут после отправки отчёта.

С момента подтверждения я не получал от Apple никакой информации, поэтому продолжал отправлять просьбы об обновлении статуса. 9 сентября 2020 года мне сказали, что работают над исправлением.

Потом опять в течение пяти месяцев я не получал никакой информации, а когда я спросил о статусе, мне прислали это письмо

Мне сказали, что планируют устранить проблему в ближайшем обновлении безопасности. Мне стало любопытно, почему реакция на критическую уязвимость занимает так много времени.

Я продолжал тестировать уязвимость, чтобы проверить, устранена ли она, уже не полагаясь на них. Я протестировал её 1 апреля 2021 года и понял, что патч уязвимости был выпущен в продакшен, но Apple снова меня никак не проинформировала. Я спросил их, пропатчена ли проблема, и они ответили так же — что не могут поделиться никакой информацией о состоянии.

Я терпеливо ждал обновления статуса. Спустя месяц я сам написал, что проблема была пропатчена 1 апреля и спросил, почему мне об этом не сообщили. Также я написал, что хочу опубликовать отчёт в своём блоге.

Отдел безопасности Apple спросил меня, смогу ли я показать им черновик статьи перед публикацией. После этого дело приняло неожиданный оборот.

После отправки черновика они опровергли моё заявление, сказав, что эта уязвимость не позволяет захватывать большинство аккаунтов iCloud. Вот их ответ:

Как вы видите на показанном скриншоте письма, их анализ показал, что уязвимость сработает только против аккаунтов iCloud, не защищённых кодом/паролем устройств Apple.

Я возразил, что даже если вместо отправляемого на электронную почту кода из 6 цифр запрашивается код устройства (4 или 6 цифр), то к нему всё равно применяются те же ограничения частоты запросов и он будет уязвим к атакам брутфорсом на основе условия гонки. Мы сможем определить код соответствующего устройства Apple.

Также я заметил некоторые изменения на их странице поддержки, относящейся к восстановлению забытого пароля.

На скриншоте выше показано, как выглядит страница сейчас, но до моего отчёта она выглядела иначе.

В октябре 2020 года эта страница выглядела так:

«In some cases» («в некоторых случаях») было добавлено в параграф в октябре 2020, то есть как раз после того, как мне сказали в сентябре 2020 года, что работают над исправлением.

Похоже, что всё было запланировано, страница была обновлена, чтобы подтвердить их заявление о том, что уязвимо только ограниченное число пользователей. Эта страница не обновлялась годами, но немного изменилась после моего отчёта. Это непохоже на совпадение.

Когда я спросил об этом, мне сказали, что страница обновлена из-за изменений в iOS 14. Я спросил, как связан сброс пароля при помощи доверенного адреса электронной почты/телефонного номера с iOS 14. Если это правда, то доверенный телефонный номер и адрес электронной почты использовался для сброса пароля до iOS 14? Если это так, то мой отчёт применим ко всем аккаунтам Apple. Ответа я не получил.

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

Они согласовали звонок с инженерами Apple, чтобы те объяснили, что они выяснили с процессе своего анализа и чтобы ответить на вопросы, которые у меня могут возникнуть.

Во время звонка я спросил, почему это отличается от найденной мной уязвимости. Они сказали, что код устройства не отправляется ни в какую конечную точку сервера и проверяется самим устройством. Я возразил, что произвольное устройство Apple не сможет узнать код другого устройства без связи с сервером Apple. Они сказали, что данные действительно передаются на сервер, но они проверяются при помощи криптографической операции, и что большего они рассказать не могут из соображений безопасности.

Я спросил, что будет, если разобраться в процессе шифрования при помощи реверс-инжиниринга и воссоздать его, а затем забрутфорсить сервер Apple параллельными запросами. Какого-то конкретного ответа я не получил. Они пришли к выводу, что единственный способ подобрать код устройства брутфорсом — это брутфорс устройства Apple, который невозможен из-за локальных ограничений частоты запросов в системе.

Я не мог согласиться с инженерами Apple: логично, что должна существовать возможность воссоздания действий устройства Apple при отправке данных кода устройства на сервер.

Чтобы проверить их слова, я решил убедиться в этом сам. Если они сказали правду, конечная точка проверки кода устройства должна быть уязвима к брутфорсу на основе условий гонки. Спустя несколько часов тестирования я выяснил, что у них есть SSL pinning, специфичный для конечной точки проверки кода устройства, поэтому передаваемый на сервер трафик невозможно считать при помощи MITM-прокси наподобие burp/charles.

Благодаря checkra1n я воспользовался инструментом SSL Kill Switch и смог обойти pinning и считать передаваемый на сервер трафик.

Я разобрался, что Apple использует SRP (Secure Remote Password) — PAKE-протокол, позволяющий проверить, действительно ли пользователь знает нужный пароль, не отправляя его на сервер. То есть инженеры сказали правду, устройство не отправляет код непосредственно на сервер. Вместо этого сервер и клиент выполняют математические вычисления на основе ранее известных данных для получения ключа (это больше похоже на обмен ключами по протоколу Диффи-Хеллмана).

Я не буду вдаваться в специфику SRP и сразу перейду к тому, что важно в нашем контексте.

• На сервере Apple хранятся два значения, verifier и salt, связанные с каждым пользователем, они создаются в момент задания или обновления кода устройства.
• Когда пользователь инициирует SRP-аутентификацию с именем пользователя и динамическим значением A, сервер Apple отвечает ему отправкой соли этого пользователя и динамическим значением B.
• Клиент использует полученную от сервера соль для вычисления ключа в соответствии с SRP-6a.
• Сервер использует salt и verifier для вычисления ключа в соответствии с SRP-6a.
• В конце они подтверждают друг другу, что вычисленный ключ одинаков.

Подробнее о вычислениях SRP-6a можно здесь.

SRP известен тем, что предотвращает атаки брутфорсом, поскольку для каждого пользователя имеет salt и verifier, поэтому даже если кто-то украдёт нашу базу данных, ему придётся выполнять вычислительно затратный брутфорс для выявления один за одним пароля каждого пользователя. Это даёт владельцу базы данных достаточно времени, чтобы прореагировать на кражу.

Но в нашем случае не нужно брутфорсить большое количество аккаунтов. Для входа в аккаунт iCloud и определения кода устройства достаточно брутфорса одного пользователя.

Брутфорс возможен, только если у нас есть и salt, и verifier конкретного пользователя. Обойдя SMS-код, мы можем легко выдать себя за этого пользователя и получить salt. Однако проблема заключается в verifier. Нам нужно или как-то получить verifier с сервера, или обойти ограничение частоты в конечной точке проверки ключа.

Если мы обойдём ограничение частоты запросов, то можно будет пробовать различные комбинации полученного ключа на заранее вычисленных значениях кода устройства, пока мы не подберём совпадающий ключ. Очевидно, для получения ключа каждого из кодов устройств из 4 или 6 цифр (от 0000/000000 до 9999/999999) требуется много вычислений.

При вводе кода устройства в iPhone/iPad во время сброса пароля устойство инициирует SRP-аутентификацию, отправляя пользователю токен сессии, полученный из успешной SMS-верификации. Сервер отвечает, отправляя соль соответствующего пользователя. Код устройства и соль хэшируются для последующего вычисления ключа, который отправляется на p50-escrowproxy.icloud.com/escrowproxy/api/recover для проверки, соответствует ли он ключу, вычисленному на сервере (с помощью динамического значения, salt и verifier).

Отправляемый для проверки ключа POST-запрос выглядит так:

Строковая метка содержит все описанные выше данные, но она отправляется в формате блоба данных. До того, как начинать расшифровку блоба, первым делом я захотел проверить ограничение частоты запросов. Я отправил запрос параллельно 30 раз, чтобы проверить, уязвима ли конечная точка.

К моему потрясению, она не была уязвимой. Из 30 запросов 29 было отклонено с внутренней ошибкой сервера.

Ограничение частоты запросов должно выполняться или на самом сервере Apple, или в HSM (hardware security module). В любом случае, логика ограничения должна быть запрограммирована так, чтобы предотвращать угрозу гонки. Существовала очень маленькая вероятность, что эта конечная точка не была уязвимой к угрозе гонки, потому что все протестированные мной конечные точки были к ней уязвимы — валидация по SMS-коду, валидация по коду в электронном письме, двухфакторная авторизация, проверка пароля.

Если они пропатчили её после моего отчёта, уязвимость стала гораздо более серьёзной, чем я изначально думал. Благодаря брутфорсу кода устройства можно обнаружить правильный код по различию ответов. То есть мы не только можем захватить любой аккаунт iCloud, но и определить связанный с ним код устройства Apple. Даже несмотря на то, что такая атака сложна, если моё предположение верно, эта уязвимость могла хакнуть любой iPhone/iPad, имеющий код устройства из 4 или 6 цифр.

Так как теперь параллельные запросы обрабатываются правильно, я никак не смогу проверить свою догадку. Единственное, что я мог сделать — написать Apple, но по этой теме мне ничего не ответили.

4 июня 2021 года я получил от Apple электронное письмо о вознаграждении.

На веб-сайте Apple написано, что награда за захват аккаунта равна 100 тысячам долларов. За извлечение конфиденциальных данных с заблокированного устройства Apple — 250 тысячам долларов. Мой отчёт соответствовал обоим случаям (если предположить, что конечная точка проверки кода устройства была пропатчена после отправки отчёта), поэтому моё вознаграждение должно было равняться 350 тысячам долларов. Даже если бы они решили наградить за самый важный из двух случаев, она всё равно должна быть равной 250 тысячам.

Продажа подобных уязвимостей государству или частным баунти-программам наподобие zerodium могло принести гораздо больше денег. Но я выбрал этичный путь и не ожидал ничего другого, кроме как указанных Apple сумм наград.

Однако 18000 долларов даже не близки к истинной награде. Предположим, что мои допущения неверны и конечная точка проверки кода устройства Apple не была уязвимой до моего отчёта. Но даже и в этом случае назначенная награда несправедлива, если взглянуть на серьёзность уязвимости:

• Обход двухфакторной аутентификации. По сути, благодаря обходу 2FA как будто и не существует. Люди, полагающиеся на 2FA, уязвимы. Само по себе это является крупной уязвимостью.
• Обход ограничений частоты запросов проверки пароля. Все аккаунты Apple ID, имеющие распространённые/слабые/хакнутые пароли, уязвимы даже при включенной двухфакторной аутентификации. После взлома атакующий может отслеживать местоположение устройства, а также удалённо стирать с него данные. Хак iCloud знаменитостей в 2014 году был вызван в основном слабыми паролями.
• Обход верификации по SMS. Если мы знаем код или пароль устройства, связанного с аккаунтом iCloud. Допустим, кто-то из ваших друзей или родственников знает код вашего устройства, тогда при помощи этой уязвимости он может захватить ваш аккаунт iCloud и полностью стереть все данные с устройства через Интернет, без необходимости физического доступа.
• Мы можем захватить все Apple ID, не связанные с защищённым кодом устройством Apple благодаря обходу кода верификации по SMS и электронной почте, то есть
  • Любое устройство Apple без кода или пароля, например, у пользователей, которые отключили или не задали код/пароль.
  • Любой Apple ID, созданный без устройства Apple, например, в браузерах или в приложении для Android и не используемый в защищённых паролем устройствах Apple
  • Например больше 50 миллионов пользователей Android скачало приложение Apple Music. Большинство из них, вероятно, не использовало устройства Apple. Однако они всё равно являются пользователями Apple и их информация (кредитные карты, платёжные адреса, подробности подписки и т.п.) может быть раскрыта.

Компания могла и не выплачивать максимальную сумму награды за захват аккаунта iCloud (100 тысяч долларов), но должна была хотя бы выплатить близкую сумму, учитывая важность уязвимости.

Проделав всю эту работу и прождав целый год, я так и не получил заслуженного мной из-за несправедливого решения Apple. Поэтому я отказался получать награду и сообщил им, что это было несправедливо. Я попросил пересмотреть решение о сумме награды или позволить мне опубликовать отчёт со всей информацией. Ответа на мои письма не было. Поэтому я решил опубликовать свою статью, не дожидаясь бесконечно их ответа.

То есть я передал свои исследования Apple бесплатно, чтобы не брать несправедливо назначенную награду.

Я призываю отдел безопасности Apple быть более открытым и справедливым, хотя бы в будущем. Также я бы хотел поблагодарить Apple за пропатченную уязвимость.

Повторюсь — уязвимость полностью устранена и описанные в статье сценарии больше не работают. Благодарю за чтение статьи!

Источник