Эта статья посвящена тому, как я обнаружил уязвимость в конечной точке восстановления пароля 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.
Поэтому я решил, что сервер неуязвим к подобному типу атак, но у меня ещё оставалась надежда, так как это общие ограничения частоты запросов для всего сервера, не относящиеся конкретно к конечной точке проверки кода.
Проведя тестирование, я выяснил следующее:
- 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).
- Существует два ограничения на частоту запросов, о которых мы уже говорили, одно срабатывает, если мы отправим больше 5 запросов конечной точке восстановления пароля (http://iforgot.apple.com/password/verify/smscode), второе относится к серверу Apple и срабатывает, когда мы отправляем больше 6 параллельных POST-запросов.
- Оба эти ограничения на частоту связаны с IP-адресом конкретного сервера Apple, то есть мы всё равно можем отправлять запросы (хоть и в пределах ограничений) на другой IP-адрес сервера Apple.
- Мы можем отправлять до 6 параллельных запросов IP-адресу сервера Apple (привязав iforgot.apple.com к IP-адресу) с одного клиентского IP-адреса в соответствии с их ограничениями. Как сказано выше, резолвится 6 IP-адресов Apple. То есть с одного IP-адреса мы можем отправлять до 36 запросов на 6 IP-адресов Apple (6 x 6 = 36).
- Следовательно, атакующему потребуется 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.
Также я заметил некоторые изменения на их странице поддержки, относящейся к восстановлению забытого пароля.
Ссылка: https://support.apple.com/en-in/HT201487.
На скриншоте выше показано, как выглядит страница сейчас, но до моего отчёта она выглядела иначе.
В октябре 2020 года эта страница выглядела так:
Ссылка из веб-архива: http://web.archive.org/web/20201005172245/https://support.apple.com/en-in/HT201487.
«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 сумм наград.
https://developer.apple.com/security-bounty/payouts/
Однако 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 за пропатченную уязвимость.
Повторюсь — уязвимость полностью устранена и описанные в статье сценарии больше не работают. Благодарю за чтение статьи!
Комментарии (62)
Tsimur_S
31.07.2021 12:16Насколько легально, с точки зрения законодательства РФ, продавать эксплойты в zerodium?
azatfr
02.08.2021 12:08Как то такУК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
(в ред. Федерального закона от 07.12.2011 N 420-ФЗ)
(см. текст в предыдущей «редакции»)
"«1. Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации, — наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до четырех лет, либо лишением свободы на тот же срок со штрафом в размере до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до восемнадцати месяцев.
2. Деяния, предусмотренные частью первой настоящей статьи, совершенные группой лиц по предварительному сговору или организованной группой либо лицом с использованием своего служебного положения, а равно причинившие крупный ущерб или совершенные из корыстной заинтересованности, — наказываются ограничением свободы на срок до четырех лет, либо принудительными работами на срок до пяти лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет или без такового, либо лишением свободы на срок до пяти лет со штрафом в размере от ста тысяч до двухсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от двух до трех лет или без такового и с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет или без такового.
»«3. Деяния, предусмотренные частями первой или второй настоящей статьи, если они повлекли тяжкие последствия или создали угрозу их наступления, — наказываются лишением свободы на срок до семи лет.
v1000
31.07.2021 12:47Возможность получить коды на доверенный телефон с одной стороны облегчает разблокировку своего телефона, с другой стороны, открывает возможности для социальной инженерии для получения кодов не напрямую, а через родственников или других доверенных лиц, которые могут не быть хорошо подкованы в сфере ИБ.
nullc0de
31.07.2021 12:50+39ЧСВ у автора в статье просто зашкаливает. Так и не была показана успешная реализация атаки, куча теоретических рассуждений в сферическом вакууме, и много текста о том какой автор молодец… В конце убило, что автор отказался от вознаграждения в $18000, ведь он такой молодец и достоин минимум награды в $100000, а лучше в $250000. Не говоря про то, что много воды.
abyrkov
31.07.2021 18:31+1Так и не была показана успешная реализация атаки, куча теоретических рассуждений в сферическом вакууме
Иначе бы статья называлась "Почему я отказался платить 18 тысяч долларов Apple" :D
Теоретические рассуждения, видимо, были как способ объяснить несведущим детали, но получилось не очень удачно, по крайней мере, в переводе.
kompilainenn2
31.07.2021 20:01странная логика, я бы понял если бы он обижался, что ему дали 0 денег, но ведь предлагали достаточно немало
AlexDeluxe
31.07.2021 21:00+1Учитывая сколько он работы проделал, 18к это мало для США. Тем более, что Microsoft за похожую уязвимость заплатила ему 50к, а у Apple очевидно денег побольше
burzooom
01.08.2021 11:55+3Собственный капитал Microsoft: ▲118 млрд $
Собственный капитал Apple: ▼65,3 млрд $
visse
05.08.2021 18:09Учитывая сколько он работы проделал, 18к это мало для США
Никто не спорит, что он проделал немало работы, но выше было весьма резонно замечено, что успешной реализации так, по сути, и не было продемонстрировано.
Участвуя в ББ надо отдавать себе отчёт в том, что компания не обязана отсыпать золотые горы, просто если что-то возможно теоретически/если сойдутся звёзы и прочее подобное - чем больше кондиций для проведения атаки, тем меньше будет вознаграждение, и в таких ситуациях всё изначально будет довольно жидко. Если к этому ещё подключать напористость и агрессию, пусть даже пассивную, то шансы на адекватный исход будут ещё ниже.
Ну и, вдовесок, можно сказать, что ББ - это про деньги и коммерцию, то есть изначально у многих компаний будет позиция просто по факту платить как можно меньше (если вообще платить), при этом получая важную, а иногда и критическую, для себя информацию. Чем больше воды будет в репорте исследователя и чем меньше будет конкретных фактов и доказательств пробития цели/получения доступов/etc., тем меньше шансы получить хоть что-то вообще в итоге. Уже много лет как обсуждаются факты эксплуатации самой идеи ББ коммерсами, и тут как-то странно изображать невинность и незнание, что так бывает просто в принципе.
Так что предлагаемые 18к$ - это ОК, хоть, очевидно, исследователь расчитывал на куда более крупное вознаграждение. Вместо денег он предпочёл написать материал о том, какие коммерсы - шок! - несправедливые и подлые. Ну, «добро пожаловать во взрослый мир»
visse
05.08.2021 18:09Учитывая сколько он работы проделал, 18к это мало для США
Никто не спорит, что он проделал немало работы, но выше было весьма резонно замечено, что успешной реализации так, по сути, и не было продемонстрировано.
Участвуя в ББ надо отдавать себе отчёт в том, что компания не обязана отсыпать золотые горы, просто если что-то возможно теоретически/если сойдутся звёзы и прочее подобное - чем больше кондиций для проведения атаки, тем меньше будет вознаграждение, и в таких ситуациях всё изначально будет довольно жидко. Если к этому ещё подключать напористость и агрессию, пусть даже пассивную, то шансы на адекватный исход будут ещё ниже.
Ну и, вдовесок, можно сказать, что ББ - это про деньги и коммерцию, то есть изначально у многих компаний будет позиция просто по факту платить как можно меньше (если вообще платить), при этом получая важную, а иногда и критическую, для себя информацию. Чем больше воды будет в репорте исследователя и чем меньше будет конкретных фактов и доказательств пробития цели/получения доступов/etc., тем меньше шансы получить хоть что-то вообще в итоге. Уже много лет как обсуждаются факты эксплуатации самой идеи ББ коммерсами, и тут как-то странно изображать невинность и незнание, что так бывает просто в принципе.
Так что предлагаемые 18к$ - это ОК, хоть, очевидно, исследователь расчитывал на куда более крупное вознаграждение. Вместо денег он предпочёл написать материал о том, какие коммерсы - шок! - несправедливые и подлые. Ну, «добро пожаловать во взрослый мир»
Diamos
01.08.2021 16:13$18k для спеца такого уровня — просто плевок в лицо. Тем более, что уязвимость действительно серьезная. На счет ЧСВ — чисто ваша субъективщина. Чела неуважительно игнорили почти год, а потом вообще чуть ли не дураком сделали.
nullc0de
01.08.2021 16:33-2Какого уровня? Из статьи даже не понятно были ли уязвимость на самом деле, и куча воды с размышлениями в сферическом вакууме. За такие уязвимости никогда не платили. Судя по статье, из Apple ему готовы были заплатить довольно приличную сумму за то, что даже уязвимостью нельзя назвать. И не была проведена успешная атака, и еще главное у человека совсем туго с комбинаторикой. Статья просто хайповая, не более того… И кто действительно разбирается, понимает, что статья это полная вода, и сложность атаки значительно сложнее чем написана в статье и за такую «уязвимость» $18000 это переплата с лихвой. Такую уязвимость ни одна уважающая себя security компания не купит. Сколько уязвимостей вы нашли сами и продали, чтобы рассуждать, что заплатили мало и это плевок в лицо?
Diamos
01.08.2021 17:53+8Какого уровня?
Посмотрите его остальные статьи. Чел профессионально занимается этим и довольно успешно.Из статьи даже не понятно были ли уязвимость на самом деле
То есть, первый ответ Apple, в котором они признали проблему после получения видео с демонстрацией, вы не заметили случайно или притворяетесь шлангом в попытках отстоять свое мнение?За такие уязвимости никогда не платили.
Подобная категоричность весьма ошибочна, как минимум потому что вы не можете это доказать.И кто действительно разбирается, понимает, что статья это полная вода
Кто действительно разбирается, тому вполне достаточно идеи, описанной в статье для объективной оценки подобного вектора атаки.Такую уязвимость ни одна уважающая себя security компания не купит.
И снова безосновательная категоричность.Сколько уязвимостей вы нашли сами и продали, чтобы рассуждать, что заплатили мало и это плевок в лицо?
Для того, чтобы оценить вкус молока, не обязательно быть коровой, которая его производит.
Переход на суждение личности оппонента вскрыл ваше истинное лицо, которое в целом было видно еще с первого выпада в адрес автора.nullc0de
01.08.2021 19:13-2То есть, первый ответ Apple, в котором они признали проблему после получения видео с демонстрацией, вы не заметили случайно или притворяетесь шлангом в попытках отстоять свое мнение?
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?Кто действительно разбирается, тому вполне достаточно идеи, описанной в статье для объективной оценки подобного вектора атаки.
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?Для того, чтобы оценить вкус молока, не обязательно быть коровой, которая его производит.
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
Frankenstine
02.08.2021 17:52+1Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
"I reported this information with detailed reproduction steps and a video demonstrating the bypass to Apple security team on July 1st, 2020. Apple security team acknowledged and triaged the issue with in few minutes of report."
Вы пишете что скриншот легко подделать, но видео подделать так же легко. Единственный способ убедиться что эксплойт рабочий - повторить его применение. Однако, дыра запатчена и повторить её применение невозможно. Таким образом, даже если бы автор не просто написал бы это словами, но и приложил в общественный доступ видео эксплуатации уязвимости, никто не смог бы подтвердить что это не монтаж а реальный эксплойт, то есть вы хотите невозможного.
Вам остаётся либо верить автору, либо не верить - ни подтвердить, ни опровергнуть его слова (и даже видео, было бы оно доступно) вы (или кто либо другой) не можете.
visse
05.08.2021 19:43Однако, дыра запатчена и повторить её применение невозможно.
По логике вещей, сам факт триажа говорит о том,что уязвимость есть, она официально подтверждена и принята в работу, и на этом все размышления о том, была ли вообще уязвимость или нет, должны завершаться.
Другое дело, что исследователь изначально мог налить воды и дать повод для манёвра команде безопасников Apple, чтобы максимально сбить стоимость своей находки.
Проще говоря, как мне кажется: 0 - финансовые ожидания исследователя были сильно завышены изначально (это могло сыграть свою роль ещё в процессе написания отчёта); 1 - его просто кинули на какую-то часть денег.
Frankenstine
06.08.2021 17:08Я продолжал тестировать уязвимость, чтобы проверить, устранена ли она, уже не полагаясь на них. Я протестировал её 1 апреля 2021 года и понял, что патч уязвимости был выпущен в продакшен, но Apple снова меня никак не проинформировала.
У Apple есть официальный "прейскурант" по уязвимостям, в котором отсутствует $18к и планка начинается с $25к за получение персональных данных, а за контроль над аккаунтом без участия владельца уже $100k, о чём в тексте статьи говорится в разжованном виде. Вы же начинаете придумывать какие-то "завышенные ожидания", наверное основываясь на понятии российского МРОТ.
Так что статья о том, как вы нашли клад стоимостью 100к, а вам за него предложили лишь 18к и вы демонстративно от них отказались так как это очевидное жлобство.
visse
06.08.2021 17:52Вы же начинаете придумывать какие-то "завышенные ожидания"
Ссылаетесь на официальный сайт с ориентировочными расценками за баунти, и почему-то упустили едва ли не ключевую деталь:
Bounty payments are determined by the level of access or execution obtained by the reported issue, modified by the quality of the report.
и внизу страницы:
The top payouts in each category are reserved for high quality reports and are meant to reflect significant effort, and as such are applicable to issues that impact all or most Apple platforms, or that circumvent the full set of latest technology mitigations available. Payouts vary based on available hardware and software mitigations that must be bypassed for successful exploitation.
Иначе говоря, на странице указаны цены за эталонные отчёты и весомый импакт найденной уязвимости. Так что его "разоблачающая коммерсов" статья и отказ от 18k$ напоминают как раз завышенные изначально ожидания, а а не акт вопиющей несправедливости.
Frankenstine
08.08.2021 11:51Ну вот по описанию тут как раз серьёзность проблемы к высшей планке "ценника", а оценили на "плинтус".
Компания могла и не выплачивать максимальную сумму награды за захват аккаунта iCloud (100 тысяч долларов), но должна была хотя бы выплатить близкую сумму, учитывая важность уязвимости.
visse
08.08.2021 16:54Ну вот по описанию тут как раз серьёзность проблемы к высшей планке "ценника"
Давайте только не забывать пару важных нюансов:
автор оригинального материала - выходец из Индии, про особенности их менталитета надо что-то напоминать? Заметьте: не ставлю под сомнение навыки и опыт конкретного исследователя, но менталитет своё дело делает, об этом чуть ниже.
ориентироваться на описанное в материале (речть только про оригинал, так как перевод хромой) - это выслушать только одну сторону конфликта, в который втягивается IT-тусовка подобными "разоблачениями".
Далее TL;DR:
After my Instagram account takeover vulnerability, I realized that many other services are vulnerable to race hazard based brute forcing. So I kept reporting the same with the affected service providers like Microsoft, Apple and a few others.
So to exploit this vulnerability, we need to know the trusted phone number as well as their email address to request OTP and will have to try all the possibilities of the 6 digit code, that would be around 1 million attempts (10 ^ 6).
After some testing, I found a few things:
<...> the attacker would require 28K IP addresses to send up to 1 million requests to successfully verify the 6 digit code.
28k IP addresses looks easy if you use cloud service providers, but here comes the hardest part, apple server has a strange behavior when we try to send POST requests from cloud service providers like AWS, Google cloud, etc.
It makes the attack harder for those who rely on reputed cloud services like AWS. I kept trying various providers and finally found a few service providers their network IPs are not blacklisted.
Of course the attack isn’t easy to do, we need to have a proper setup to successfully exploit this vulnerability.
На этом, в принципе, сильная сторона его исследования заканчивается, и, заметим, триаж был спустя несколько минут после уведомления Apple о найденной уязвимости. Дальше весь материал - это ущемлённое Эго, догадки, предположения и отчаяние в виде угроз опубликовать материал без дальнейшего сотрудничества и т.д. и т.п. К вопросу о менталитете. Ошибка автора была в том, что после первой удачи он сразу пошёл сдавать уязвимость, вместо дальнейшего исследования и получения более серьёзных и стабильных доказательств, о чём впоследствии, как видно, сильно пожалел:
If they did patch it after my report, the vulnerability became a lot more severe than what I initially thought. Through bruteforcing the passcode, we will be able to identify the correct passcode by differentiating the responses. So we not only can takeover any iCloud account but also discover the passcode of the Apple device associated with it. Even though the attack is complex, this vulnerability could hack any iPhone / iPad that has 4 digit / 6 digit numeric passcode if my assumption is right.
Since it is now validating the concurrent requests properly, there is no way for me to verify my claim, the only way I can confirm this is by writing to Apple but they aren’t giving any response in this regard.
Иными словами, это просто его догадки как оно могло быть, но уже без возможности узнать наверняка:
Even though the attack is complex, this vulnerability could hack any iPhone / iPad that has 4 digit / 6 digit numeric passcode if my assumption is right.
Обратите особое внимание на эти слова автора:
if my assumption is right
Сотрудники компании, разумеется, такой информацией ни с кем делиться не будут просто в принципе, и на что он расчитывал тут, как опытный баунти-хантер:
by writing to Apple but they aren’t giving any response in this regard
я даже стесняюсь предположить.
Вообще, тут можно отдельную статью писать с разбором оригинала, в качестве примера, когда ожидаемая награда затмила способность мыслить логически.
Frankenstine
09.08.2021 08:38Вы ушли в какие-то дебри разбора личности вместо разбора сути.
Обратите особое внимание на эти слова автора:
if my assumption is right
Обратите внимание что автор вам сразу же отвечает на это:
Lets say all my assumptions are wrong and Apple passcode verifying endpoint wasn’t vulnerable before my report. Even then the given bounty is not fair looking at the impact of the vulnerability as given below.
visse
09.08.2021 10:55Какие дебри, если вместо фактов автор начал лить воду? Факты закончились у него на стадии обращения в компанию. И "личность" к сути имеет прямое отношение, если что.
Even then the given bounty is not fair looking at the impact of the vulnerability as given below.
Как уже выше правильно заметили, корова сама оценивает вкус молока. Это бред. У него на выходе получилась сложноэксплуатируемая уязвимость, нацеленная против единичных пользователей. И 18k$ за это - вполне нормально.
Frankenstine
09.08.2021 17:35Человек обнаружил некую уязвимость. Написал в поддержку Яббл, получил какой-то ответ, но он его не устроил. Человек написал статью с примерным изложением событий. Другие люди стали обсуждать "да ты ничего не предъявил, у тебя одна вода".
А он что, должен был? Вы всё-таки не поддержка Яббл и в подробности вас посвящать никто не обязывался.
visse
09.08.2021 18:29Вы точно на техническом ресурсе, а не на гуманитарном?
Человек написал статью с примерным изложением событий.
Когда речь идёт о цифре, и, тем более, об ИБ/хакинге/ББ, то "примерное изложение" недопустимо. Есть факты, есть PoC, и на основании всего этого и должно составляться описание той или иной ситуации. Тем боее, если изначальный посыл такого материала - это разборы полётов и претензии к кому-то на основании чего-то.
Другие люди стали обсуждать "да ты ничего не предъявил, у тебя одна вода".
Именно по этой причине и стали писать, что там одна вода, потому что так и есть.
А он что, должен был?
Если он взялся
в связи с ущемлённым Эгопо личной инициативенакидывать говно на вентиляторписать статью, то да, надо было писать всё же по-делу и с минимумом соплей. Иначе статья какуюцель преследует и на какую аудиторию расчитана?Вы всё-таки не поддержка Яббл и в подробности вас посвящать никто не обязывался.
А я претендую? Вы забавно пытаетесь акценты смещать.
Frankenstine
10.08.2021 11:25По-моему вы забыли, что это перевод статьи с совершенно другого ресурса, и автор (статьи, а не перевода) совершенно не обязан писать её под вас лично или "высокие стандарты хабра".
Вы можете обсуждать, стоило ли перевод публиковать на хабре или нет, но претензии предъявлять к автору изначального текста - это, извините, "со своим уставом в чужой монастырь".
visse
10.08.2021 12:43По-моему вы забыли
С подключением, я изначально говорил об оригинале. Но вы, видимо, не читали ни то, ни другое, ни комментарии, но что-то очень хотите сказать этому миру, хотя сказать по данному вопросу особо и нечего, судя по отсутствию каких-то вменяемых мыслей. Дали ссылку на страницу с расценками по ББ Apple, но как-то упустили всю суть того, что на ней увидели. Вас устраивает "примерное изложение" вместо логики и фактов, а про ББ, видимо, вы только из перевода узнали.
не обязан писать её под вас лично или "высокие стандарты хабра"
При чём здесь я и какие-то "стандарты"? Есть факты, есть вода. Если автор пишет ересь, то конкретно ко мне это отношения не имеет, равно как и к Хабру в целом, но это никак не мешает обсуждению и пониманию (не в вашем случае, как видно, но всё же) что есть что.
Вы можете обсуждать, стоило ли перевод публиковать на хабре или нет
А я обсуждал это? Вы опять какой-то бред пишете и о чём-то о своём рассуждаете, что ко мне и к обсуждаемой теме отношения не имеет.
Frankenstine
10.08.2021 13:38Если вы изначально говорили об оригинале, то какого чёрта вы пишете
Вы точно на техническом ресурсе, а не на гуманитарном?
?
В рамках ресурса, на котором опубликован был оригинал, какие у вас к нему вопросы? Почему вы их задаёте здесь, мне, а не автору статьи, там?
Если автор пишет ересь
то это ваше личное мнение, с которым я не согласен. На том и закончим этот бессмысленный тред.
visse
10.08.2021 14:54Если вы изначально говорили об оригинале, то какого чёрта вы пишете
Если вы не понимаете смысла прочитанного, то я тут ничем не смогу помочь, увы. Зато у вас хорошо получается додумывать за собеседника.
В рамках ресурса, на котором опубликован был оригинал, какие у вас к нему вопросы? Почему вы их задаёте здесь, мне, а не автору статьи, там?
С логикой, как видно, тоже проблемы. Понятно.
то это ваше личное мнение, с которым я не согласен
Без проблем, имеете полное право. По вашим сообщениям без лишних слов понятно, что в данной сфере вы ноль, но почему-то пытаетесь спорить, не подключая хотя бы логику к процессу, что делает общение более эпичным.
На том и закончим этот бессмысленный тред.
Согласен.
greatvovan
05.08.2021 04:20$18K это немного в США – два-три месяца прожить (а в Кремниевой долине и того меньше).
Apple сама признала уязвимость, как минимум, для некоторых аккаунтов. Не понятно, в чём противоречие их же полиси.
visse
09.08.2021 01:27Apple сама признала уязвимость
И они готовы были за неё заплатить 18k$.
Не понятно, в чём противоречие их же полиси.
Противоречия нет, иначе бы не было триажа и назначения вознаграждения за предоставленную информацию.
AlexanderS
31.07.2021 13:33+14Иногда просто поразительно до каких пределов вырастает человеческая то ли жадность, то ли глупость, то ли тупость. Можно подумать, что от корпорации много убыло бы при выплате справедливого вознаграждения за столь серьёзную уязвимость. Человек реально подтянул безопасность ведь.
visse
05.08.2021 20:35Пора осознать и признать, что баг-баунти - это, прежде всего, коммерция, и перестать ожидать от таких программ честного и справедливого подхода. Вся эта история про деньги, и тут изначально было ясно, что "этическую" часть будут нагло эксплуатировать в любом случае, рано или поздно.
при выплате справедливого вознаграждения
Коммерция не про справедливость, а про деньги. Да и в финансовом вопросе всё сильно разнится, даже в этом конкретном случае: исследователь хотел 1/4 мульта, а по меркам безопасников Apple эта находка стоит 18 килобаксов. Об объективности тут говорить будет сложно в любом случае.
AlexanderS
05.08.2021 21:16Понятно, что коммерция — это максимум выгоды при минимуме вложений. Но есть определенные вещи, экономить на который — это неприемлемый будущий ущерб. Одно дело, если косяки в дизайне. Но если у тебя будет дыра в механизме авторизации, то… это может далеко аукнуться. Казалось бы — тут и денег никаких не жалко. Но вот нет же… Наверное, у меня мозги не так устроены, что бы понимать такую логику поведения и, возможно, оттого я технарь по жизни, а не бизнесмен)
visse
05.08.2021 21:46Согласен с вами полностью, но я сам бывал в подобных ситуациях, которые +/- описаны в материале. По своему опыту уяснил, что сотрудники +/- крупных компаний зачастую вообще не обеспокоены вопросами той же безопасности. Они сидят на приличной зарплате в уютном офисе, у них есть юристы на случай чего, так что вся эта история с «этикой» больше похожа на какую-то игру с элементами цирка, которая иногда этих самых сотрудников компании прилично утомляет.
Наверное, у меня мозги не так устроены, что бы понимать такую логику поведения и, возможно, оттого я технарь по жизни, а не бизнесмен)
А это ещё один нюанс, который заметил по своему опыту: есть большая разница в мышлении, условно говоря, «белых» и «чёрных» шляп. Конфликт начинается с того, что ББ - это поле, якобы, «белых» шляп, со всеми дальнейшими последствиями, и восприниматься вся ифнормация будет соответственно, я бы даже сказал с некоторыми оттенками чего-то идеального, что в реальной практике будет выглядеть совсем иначе.
AlexanderS
05.08.2021 22:34Тут еще причина в том, что в крупных конторах всё сильно забюрократизировано со всеми вытекающими. Не зря же транскорпорации порой сравнивают с государствами по неповоротливости системы управления. Поэтому порой изначально неплохая идея дискредитируется качеством исполнения.
Но, например мне, всё же трудно понять насколько должно быть всё бюрократически запущено и быть, так скажем, неидеальным, когда исследователь приходит к крупному автогиганту с уязвимостью в системе дистанционного доступа к автомобилю, а производитель мало того что полгода ничего не делает и денег не выплачивает, так потом ещё и в суд подаёт на человека, который всё это опубликовал, так как иначе заставить вендора прикрыть дыру заставить просто невозможно. Это на каком уровне развития должно находится сознание людей принимающие такие решения и организующих программу баунти именно так, что она вместо помощи компании становится мощным и непробиваемым фильтром? И ведь эти люди организуют процессы, которые приносят нам, пользователя, продукты… о безопасности которых лучше не задумываться)visse
05.08.2021 23:55Тут еще причина в том, что в крупных конторах всё сильно забюрократизировано со всеми вытекающими.
Именно, и при таком сценарии даже самые благие начинания будут угасать на фоне всей этой бюрократической канители.
Но, например мне, всё же трудно понять насколько должно быть всё бюрократически запущено и быть, так скажем, неидеальным, когда исследователь приходит к крупному автогиганту с уязвимостью
Если чуть в общем плане взглянуть на картину, то тут я бы выделил ряд нюансов:
исследователи сами согласились на концепцию ББ при всех её заведомо очевидных слабых местах;
те же исследователи прекрасно должны понимать, на чьём поле они играют - это коммерсы, которые, прежде всего, будут думать о деньгах, личной выгоде и будут неплохо так защищены юридически, если вдруг кто-то начнёт устанавливать свои порядки;
сама концепция «этики» - это игра в одни ворота чаще всего, начиная с банального неуважительного общения и заканчивая чем-то в духе того, что описано в материале, когда обесценивается проделанная работа.
Это на каком уровне развития должно находится сознание людей принимающие такие решения и организующих программу баунти именно так, что она вместо помощи компании становится мощным и непробиваемым фильтром?
Это человеческий фактор, и его проявление было более чем очевидно ещё на стадии развития баг-баунти программ как таковых. В остальном это был лишь вопрос времени, когда подобное отношение к независимым исследователям станет повсеместным, наглым и не слишком скрываемым. Сейчас, по сути, этап принятия решения самими специалистами, хотят они и дальше весь этот «Ералаш» поддерживать, или же настало время что-то менять.
И ведь эти люди организуют процессы, которые приносят нам, пользователя, продукты… о безопасности которых лучше не задумываться)
Шатко-валко, но оно же как-то работает :) Многим достаточно и этого примитивного уровня.
Lelant0s
31.07.2021 15:08+2Какое-то гадливое ощущение от поведения Apple после прочитанного
napa3um
01.08.2021 14:35+2Такое поведение получается у любой крупной компании, состоящей из более одного отдела и более одного сотрудника в них. По сути, ответы писали очень разные люди по очень разным мотивам и очень разным описаниям проблемы, и в этот раз их поведение сложилось не во что-то «справедливое». Но в целом это вообще случайность - получить ответ на свой сколь-нибудь отклоняющийся от корпоративного сценария вопрос :).
uhf
31.07.2021 21:24+2Мы можем отправлять до 6 параллельных запросов IP-адресу сервера Apple (привязав iforgot.apple.com к IP-адресу) с одного клиентского IP-адреса в соответствии с их ограничениями. Как сказано выше, резолвится 6 IP-адресов Apple. То есть с одного IP-адреса мы можем отправлять до 36 запросов на 6 IP-адресов Apple (6 x 6 = 36).
Значит у каждого сервера Apple свой счетчик ограничений, это понятно.
Но выше в статье написано, что аккаунт (не IP) блокируется после пяти неверных попыток ввода кода. То есть аккаунт на всех серверах должен залочиться после проверок 36 кодов суммарно (если параллельные запросы на каждом сервере считаются корректно) либо 180 кодов (если нет).
В этом и заключается уязвимость? Если да, то 18000 долларов за нее более чем достаточно.
GrigorGri
01.08.2021 01:09+2Насколько я понял статью, дело тут в том, что запросы параллельные считаются не так как последовательные.
То есть отправил одновременно с 1 000 000 ип адресов запрос, и сервер всем ответит, и лишь после этого обновит счётчик запросов (то есть обновление счётчика происходит не сразу, пропуская запросы близкие по времени отправки)
gudvinr
01.08.2021 02:09Скорее всего "гонка данных" заключается в том, что информация о количестве попыток ввода читается с физически распределённых реплик, и если отправить запросы на разные серверы в рамках довольно короткого промежутка времени, эти запросы успеют выполниться до того, как на реплики, с которых читается информация, поступят актуальные данные.
Ark1774
01.08.2021 16:00+3На Хабре из за подобной проблемы периодически появляются дублированные комменты.
nullc0de
01.08.2021 16:42+1gudvinr это итак понятно, только на практике сложность такой атаки значительно сложее, даже если у вас будет 28000 IP адресов.
MrRitm
03.08.2021 13:40В коментариях несколько раз написано "сложность значительно выше". А почему собственно? Ну т.е. в теории нам надо с 28000 (да хоть с 1000000) адресов отправить запросы. Делаем отправлялку запросов (на основе cURL например) и управляющий сервер. Отправлялку можем хоть через ansible залить довольно быстро на большое количество хостов. Опять-же никто не мешает нам в рамках 1 физической машины запустить множество экземпляров нашей отправлялки запросов каждый из которых будет работать через TOR принудительно для себя делая новый маршрут (получая новую точку выхода). Естественно синхронизируем всё наше добро отправляя не каждому инстансу задачу по очереди, а отправляя всем задачу "в N-часов ровно выполнить запрос M" и ждём, когда выполнит. Ну а далее уже в соответствии с нашей "бизнес-логикой" обрабатываем результат. Т.е. 10 VPS могут выполнить 2800 запросов каждая, адреса будут разные, всё произойдёт в один момент времени. Что-то не учёл или сложность была не в этом?
visse
09.08.2021 01:43В коментариях несколько раз написано "сложность значительно выше". А почему собственно?
Вы упростили в своём размышлении ряд деталей, но даже при таком раскладе, выявленная уязвимость для успешной атаки требует довольно замороченной инфраструктуры, поднять которую будет стоить денег. Это раз. Два - это выполнение условия:
It makes the attack harder for those who rely on reputed cloud services like AWS. I kept trying various providers and finally found a few service providers their network IPs are not blacklisted.
И всё это ради:
But, in our case, we don’t have to bruteforce a large number of accounts. Bruteforcing single user is enough to get into their iCloud account as well as finding their passcode.
То есть данная уязвимость предполагает не массовую, а таргетированную атаку на одного пользователя. Более того, которая ещё зависит от ряда условий, не вспоминая про необходимую инфраструктуру.
al_sh
02.08.2021 14:42Айфон жены спокойно разблокирует ее сестра по фэисади и наоборот, хотя они не близняшки и даже не похожи совсем. А декларировали, что различает даже близнецов
Jalt
02.08.2021 21:54А декларировали, что различает даже близнецов
Они этого никогда не декларировали. Если посмотрите даже оригинальное видео, где анонсировали iPhone X и FaceID, там Craig шутит, что телефон можно будет разблокировать, если у вас есть "злой близнец", а также с самого начала была оговорка, что в некоторых случаях близкие родственники могут распознаваться как одно лицо.
https://support.apple.com/en-us/HT208108
The probability that a random person in the population could look at your iPhone or iPad Pro and unlock it using Face ID is approximately 1 in 1,000,000 with a single enrolled appearance. As an additional protection, Face ID allows only five unsuccessful match attempts before a passcode is required. The statistical probability is different for twins and siblings that look like you and among children under the age of 13, because their distinct facial features may not have fully developed. If you're concerned about this, we recommend using a passcode to authenticate.
scruoge
03.08.2021 12:46Прочел первый абзац по русски, дальше читал оригинал. Уважаемый
@PatientZero, спасибо за ваш труд! А теперь - ложка дёгтя: чтобы переводить такого рода технические тексты, надо не только уметь в перевод, а ещё и в конкретную область техники, в которой этот перевод вы собираетесь делать. Или хотя-бы консультироваться с техническими специалистами в предметной области.Надеюсь - критика будет воспринята как конструктивная.
padizar
А еще в ос14 можно изменить любой пароль apple id даже под двухфакторной авторизацией. Достаточно получить доступ к устройству (знать пин-код разблокировки). Покупаем на авито украденный айфон. Переходим в настройки - имя пользователя - пароль и безопасность - изменить пароль. Меняем пароль на новый без каких-либо подтверждений по почте или смс. Выходим из этого эппл ид и заходим под другим аккаунтом.
pishchin
Но можно задать 4х значный код-пароль экранного времени и запретить изменение «Учетной записи». Главное не забыть этот код. Если же включить «Учёт на всех устройствах», то код пароль будет общий для всех устройств и его можно будет достать из iCloud.
ed007
Есть деталь: что б зайти в «пароль и безопасность» надо ввести текущий пароль. Что бы после этого сменить пароль — надо ответить на вопросы
greatvovan
У меня спрашивает не пароль а код к телефону (passcode), т.е. тот же, которым разблокируется телефон. После этого появляется два поля: новый пароль и подтверждение. Я проверять на своём аккаунте не стал, но где там появляются вопросы? На следующем шаге?