Я обнаружил уязвимость, похоже, затронувшую все телефоны Google Pixel: вы можете дать мне любое заблокированное устройство Pixel, и я верну его вам разблокированным. Баг устранили в обновлении безопасности 5 ноября 2022 года.
Проблема позволяла атакующему с физическим доступом к телефону обойти меры защиты экрана блокировки (отпечаток пальца, PIN и так далее), получив полный доступ к устройству пользователя. Уязвимость зафиксирована как CVE-2022-20465; она может затронуть и устройства Android других производителей. Мои рекомендации по патчу и сырой баг-репорт, отправленные Google, можно найти здесь: feed.bugs.xdavidhu.me.
Глава 1: я забываю свой PIN-код SIM-карты
Я очень рад, что этот баг устранили. Это была самая серьёзная уязвимость из найденных мною, настолько крупная, что я начал по-настоящему переживать о сроках её устранения и о том, чтобы самому сохранять её в тайне. Возможно, я преувеличиваю, но не так уж давно ФБР сражалась с Apple почти по той же самой причине.
Я обнаружил этот баг после 24-часового путешествия. Когда я добрался до дома, заряд аккумулятора Pixel 6 составлял всего 1%. Я как раз отправлял серию текстовых сообщений, когда он разрядился. Подумав, что если не закончу разговор, то это будет выглядеть как неловкая шутка, я ринулся к зарядному устройству и снова включил телефон.
Pixel включился и запросил PIN-код SIM-карты. Обычно я его знаю, но на этот раз мне не удалось вспомнить его правильно. Понадеявшись, что смогу разобраться, я попробовал несколько комбинаций, но ввёл три неверных PIN-кода, после чего SIM-карта заблокировалась. Теперь для разблокировки мне нужен был PUK-код.
Я залез в шкаф, смог найти упаковку от SIM-карты, соскрёб покрытие и нашёл PUK-код. После ввода PUK-кода Pixel попросил меня задать новый PIN. Я сделал это и после успешного завершения процесса появился экран блокировки. Но что-то было не так:
Сразу после перезагрузки вместо обычного значка блокировки появился значок сканирования отпечатка пальца. Телефон принял отпечаток моего пальца, чего не должно было случиться, ведь после перезапуска пользователь для разблокировки устройства должен ввести хотя бы раз PIN-код или пароль экрана блокировки.
После принятия отпечатка пальца телефон застрял на странном сообщении «Pixel is starting…» и продолжал показывать его, пока я снова не перезагрузился.
Мысленно я отметил, что это странно и что это может как-то влиять на безопасность, поэтому мне стоит потом изучить вопрос. Честно говоря, я не очень люблю находить подобные поведения, когда я не ищу их специально, потому что, когда такое случается, я ощущаю одержимость необходимостью исследования. Мне казалось, я должен убедиться, что за этой странностью нет никаких серьёзных проблем, упущенных другими. Оказалось, что в данном случае они были.
Глава 2: что произошло?
Как и пообещал себе, на следующий день я приступил к изучению этого поведения. Перезапустил телефон, ввёл три раза неверный PIN-код, ввёл PUK-код, выбрал новый PIN и снова пришёл к тому же состоянию «Pixel is starting…».
Я много раз экспериментировал с этим процессом, но однажды забыл перезагрузить телефон и просто продолжил работать в обычном разблокированном состоянии. Даже не осознавая, что делаю, я заблокировал его, выполнил горячую замену из лотка SIM-карты и произвёл процесс сброса PIN-кода SIM-карты.
Как и раньше, я ввёл PUK-код и выбрал новый PIN-код. На этот раз телефон заглючил, и я оказался на своём домашнем экране. Что? Но ведь раньше он был заблокирован?
Это было пугающе странно. Я повторил процесс. Заблокировал телефон, достал и вставил SIM-карту в лоток, сбросил PIN… И снова оказался на домашнем экране. ЧЕГО?
У меня начали трястись руки. КАКОГО ЧЁРТА? ОН РАЗБЛОКИРОВАЛСЯ САМ?
Немного успокоившись, я понял, что мне и в самом деле удалось полностью обойти экран блокировки на Pixel 6 с самыми новыми патчами. Я достал свой старый Pixel 5 и попробовал воспроизвести баг на нём. Тоже сработало.
Вот процесс разблокировки в действии:
Так как атакующий может воспользоваться собственной SIM-картой с блокировкой PIN-кодом, для эксплойта этого бага не нужно ничего, кроме физического доступа. Атакующий может просто заменить SIM в устройстве жертвы, выполнить эксплойт с SIM-картой, имеющей блокировку PIN-кодом, для которой у атакующего есть PUK-код.
Глава 3: реакция Google
Я отправил отчёт. Это был самый короткий отчёт в моей жизни, он состоял всего из пяти простых шагов.
Google (точнее, Android VRP) проверила и зафиксировала внутренний баг за 37 минут. Это действительно впечатляюще. К сожалению, после этого качество и частота ответов начали снижаться.
Так как по официальному тикету общение шло не особо активно, на протяжении срока жизни этого бага я иногда получал полуофициальную информацию от сотрудников Google. На самом деле, я предпочитаю получать новости только по официальному каналу (по тикету бага), которые мог бы раскрыть, но поскольку я общался с отдельными сотрудниками, мне удавалось получать лишь фрагменты информации.
Стоит также заметить, что после отправки отчёта я изучил таблицу вознаграждений Android VRP, в которой говорится, что если сообщить о способе обхода экрана блокировки, затрагивающем несколько устройств или все устройства [Pixel], то можно получить максимальную награду в $100 тысяч. Так как мой отчёт соответствовал всем перечисленным параметрам, я уже начал думать, что есть большой шанс получить за этот баг вознаграждение в $100 тысяч.
После проверки бага, по сути, компания замолчала на месяц. Я слышал, что тикет могли закрыть как дублирующийся. Очевидно, кто-то уже сообщал о баге до меня, хотя именно мой отчёт заставил компанию зашевелиться. Наверно, при обработке первого отчёта что-то пошло не так. И в самом деле, спустя 31 день после отправки отчёта меня разбудил пришедший на почту автоматический ответ, в котором говорилось, что «Android Security Team считает, что это повторный отчёт о проблеме, о которой ранее сообщил другой внешний исследователь». Это был переломный для суммы вознаграждения момент: цена бага упала с $100 тысяч до $0. Я не мог ничего поделать, кроме как смириться с тем, что мой баг теперь считается повтором и что они не заплатят.
После отправки моего отчёта прошло почти два месяца тишины. В 59-й день я попинговал тикет, запросив обновление статуса, и получил шаблонный ответ о том, что компания всё ещё работает над исправлением.
Перенесёмся в сентябрь, спустя три месяца после отправки отчёта. Я приехал в Лондон на мероприятие Google для исследователей багов под названием ESCAL8. Только что вышел патч за сентябрь 2022 года, я обновил телефон и однажды вечером в номере отеля попытался воспроизвести баг. Я надеялся, что они уже устранили его. Но нет. Я по-прежнему мог разблокировать телефон.
Это событие привело меня в ужас. Мне показалось, что устранение бага больше волнует и беспокоит меня, чем саму компанию Google. А такого быть не должно. Поэтому в тот вечер я решил обратиться к другим сотрудникам Google, которые посещали мероприятие с нами.
На следующий день я объяснил ситуацию многим людям, и даже провёл живое демо с несколькими телефонами Pixel в офисе Google. Это был тот ещё опыт. У нас не нашлось инструмента для извлечения SIM. Сначала я попробовал достать её иголкой, но каким-то образом умудрился проколоть палец в нескольких местах и рука начала кровить. Инженер Google наложил мне на палец пластырь. (Кто ещё может таким похвастаться?) Игла не подошла, поэтому я стал просить помощи у зрителей, и одна очень добрая женщина дала нам свои серьги. Это помогло! Мы поменяли SIM-карты и не без труда смогли разблокировать устройства. Теперь, когда окружающих, похоже, начала беспокоить эта проблема, я стал чувствовать себя лучше.
Я на следующий день после того, как проколол себе палец
Я установил дедлайн публикации бага на 15 октября, однако команда Android VRP сообщила, что баг не будет пропатчен в октябре. Они планировали всё на декабрь. Мне показалось, что это слишком долго, учитывая важность бага, и я решил придерживаться своего октябрьского дедлайна.
После разговора с несколькими сотрудниками Google об этом дедлайне участник команды Android VRP лично прокомментировал тикет и попросил меня договориться о созвоне насчёт этого бага. Мы устроили созвон в Meet с несколькими людьми, они были очень милы и выслушали всю мою историю о том, как я месяцами находился в неведении, получая лишь шаблонные ответы (даже сообщение о повторе, снизившее награду с $100 тысяч до $0), и как я ощущал, что этот баг больше беспокоит меня, чем Google. Они сказали, что исправление теперь запланировано на ноябрь, а не на декабрь. Однако мой дедлайн всё равно был в октябре.
Спустя две недели после этого созвона я получил новое сообщение, подтверждавшее исходную информацию, которая у меня была. В нём говорилось, что хотя мой отчёт и был повторным, так получилось только потому, что именно благодаря ему они начали работать над исправлением. Поэтому они решили сделать исключение и выплатить награду в $70 тысяч за обход экрана блокировки. Я же решил (ещё до известий о награде), что слишком опасаюсь публиковать информацию о живом баге, и что, поскольку исправление выпустят меньше чем через месяц, оно на самом деле того не стоит. Я решил подождать исправления.
Полный текст переговоров можно прочитать на feed.bugs.xdavidhu.me.
В конечном итоге, хотя поначалу этот баг для меня, как для хакера, был не очень приятным опытом, после того, как я громко «закричал» о нём, его заметили и начали реально стремиться исправить ошибку. Надеюсь, компания справедливо вознаградила и первого исследователя, обнаружившего проблему. В конце концов, мне кажется, Google справилась довольно неплохо, хотя срок жизни бага всё равно показался мне слишком долгим.
Но вы можете судить об этом сами.
Глава 4: что было причиной бага?
Так как Android — опенсорсная операционная система, коммит с устранением этой проблемы и всеми изменениями в коде выложен публично:
Первое, что меня удивило при первом изучении коммита — это количество изменённых файлов. Раньше я думал, что этот баг можно исправить единственным изменением, удалением некорректной строки кода, отвечающей за срабатывание разблокировки. Но всё было не так просто:
Прочитав описание коммита и изменения в коде, я решил, что могу приблизительно представить, что происходит внутри системы. Учтите, что я не разработчик Android, поэтому описание будет высокоуровневым.
Похоже, что в Android есть концепция «экран безопасности». Экраном безопасности могут быть различные элементы: экран ввода PIN-кода, экран сканирования отпечатка пальца, экран ввода пароля или, как в нашем случае, экран ввода PIN-кода и PUK-кода SIM-карты.
Эти экраны безопасности можно накладывать «поверх» друг друга. Например, когда телефон был заблокирован и нужно было ввести PIN-код SIM-карты, экран безопасности ввода PIN-кода SIM находился поверх экрана безопасности сканирования отпечатка пальца.
После успешного сброса PUK-кода SIM компонент сброса PUK-кода вызывал для «стека экранов безопасности» функцию
.dismiss(), что заставляло устройство закрыть текущий и показать экран безопасности, находящийся «под ним» в стеке. В нашем примере это был экран безопасности сканирования отпечатка пальца.Так как функция
.dismiss() просто закрывала текущий экран безопасности, она была уязвима к условиям гонки. Представьте, что произошло бы, если бы что-то в фоновом режиме изменило текущий экран безопасности до того, как компонент сброса PUK-кода добрался до вызова .dismiss(). Закрыл ли бы компонент PUK-кода не относящийся к нему экран безопасности, когда он наконец вызвал бы .dismiss()?Похоже, именно это и произошло. Какая-то другая часть системы в фоновом режиме отслеживала состояние SIM-карты, и, обнаружив изменение, обновила информацию о том, какой экран безопасности активен в текущий момент. Кажется, этот фоновый компонент делал обычный экран, например экран сканирования отпечатка, активным экраном безопасности ещё до того, как компонент PUK-кода мог добраться до своего вызова функции
.dismiss(). К тому моменту, когда компонент PUK вызывал функцию .dismiss(), она на самом деле закрывала экран безопасности сканирования отпечатка вместо того, чтобы закрыть экран безопасности ввода PUK-кода, как это изначально требовалось. А вызов .dismiss() для экрана безопасности сканирования отпечатка приводил к разблокировке телефона.Похоже, инженеры Android решили отрефакторить функцию
.dismiss() так, чтобы она требовала дополнительный параметр, в котором вызывающий её компонент мог указать, какой тип экрана безопасности он хочет закрыть. В нашем случае компонент PUK теперь явным образом вызывает .dismiss(SecurityMode.SimPuk), чтобы закрывались только экраны безопасности типа SimPuk. Если текущий активный экран безопасности не является экраном SimPuk (возможно, потому что, как в нашем случае, его изменил какой-то фоновый компонент), то функция закрытия ничего не сделает.Мне кажется, это довольно изящное и надёжное решение для защиты от подобных проблем, а также от будущих условий гонки. Я не ожидал, что из-за этого бага придётся вносить такие серьёзные изменения в код Android.
Комментарии (137)
jaiprakash
13.11.2022 10:26+81Без тесного личного знакомства с командой баг баунти и угроз публикации нечего и ловить, получается?
lovermann
13.11.2022 10:32+48У меня тоже сложилось впечатление, что делать это нужно так: приехать чуть ли не лично в главный офис (он вообще есть?) и прямо на рецепции кричать: "Если не дадите денег, я тут же выложу всё сначала в даркнете, а потом и вообще всезде, куда только дотянусь!", потому что в других случаях всем пох.
Popadanec
13.11.2022 12:40+14И это подтверждалось множество раз. Пока ситуация не становилась публичной, Гугл упорно отмораживалась. Что то там конкретно сломалось в механизме обратной связи.
ssj100
13.11.2022 12:59+3Притом что баг не какая-то мелочевка с использованием других уязвимостей типо flash-e, а аффектится все модели, а так как не все обновляют телефоны то и по сей день он его еще можно использовать
Ionenice
13.11.2022 13:41+12Так если его пофиксили 7 дней назад, то как раз почти все смартфоны, кроме пикселей и затронуты. Как часто прилетают и устанавливаются обновления безопасности на других смартфонах, особенно с выпуском 2-3 года назад?
Aleksid1
13.11.2022 10:41+52На самом деле это тревожный сигнал о том, что Google забюрократизирована. Если очень серьезный баг с безопасностью рассматривался месяцы.
AgentRX
13.11.2022 10:53+11Ну или есть вариант два: у них ресурсы разработчиков направлены на создание других вещей и такой баг они считают несущественным:) Сотрудники ФБР довольны, Гугл довольны, а тут кто-то надоедает:)))
panteleymonov
13.11.2022 10:57+6Я помню 10 лет назад в unity store 3 месяца уговаривал их забрать у меня лишние деньги, которые удваивались на счете если транзакция вывода денег с продаж выполнялась не верно. При этом в суппорте отвечал совсем не специалист и не понимал о чем я вообще говорю.
sshemol
14.11.2022 20:10лишние деньги?
morijndael
14.11.2022 21:19Да, но если их даже получится вывести, проблемы будут не у компании, которая допустила дыру, а у вас :р
Popadanec
13.11.2022 12:44+16Гораздо раньше, годы назад.
А на этот баг вообще забили болт и только повторный тикет с прямым общением заставил Гугл шевелиться. Это не тревожный звоночек, это уже первый этаж горит во всю.
An_private
13.11.2022 10:59+2Если текущий активный экран безопасности не является экраном
SimPuk(возможно, потому что, как в нашем случае, его изменил какой-то фоновый компонент), то функция закрытия ничего не сделает.Немного странное решение. Судя по описанию, в системе существует стек локскринов, то есть единомоментно может быть активно два и более локскринов (но только один видим). И активным (видимым) является только тот, что на вершине стека. При этом порядок локскринов в стеке может быть произвольно изменён. Но тогда если на верхний уровень вышел другой локскрин, то игнорирование запроса dismiss, приведёт к тому, что нижележащий локскрин вообще не будет закрыт. По идее dismiss должен вызываться для конкретного экземпляра локскрина и только если все локскрины в стеке были dismissed - только тогда аппарат разблокируется.
Само по себе то, что процесс может вызывать dismiss некоего объекта, который был создан не этим процессом - это уже косяк (и в тексте есть упоминание, что такое поведение приводит к некорректной работе системы).
Может, конечно, что это автор статьи неправильно всё понял.
Vizmaros
13.11.2022 12:33нижележащий локскрин вообще не будет закрыт
Запрос можно отправить повторно, что лучше для безопасности, чем предоставить доступ третьим лицамСамо по себе то, что процесс может вызывать dismiss некоего объекта, который был создан не этим процессом — это уже косяк (и в тексте есть упоминание, что такое поведение приводит к некорректной работе системы).
Судя по всему, локскрин является отдельной сущностью, которую код может создавать и удалять. К сожалению, моих знаний недостаточно что-бы понять причины такого действия. Разве что для сохранения возможности звонить 911?
Devilar
14.11.2022 07:39+3Тоже оценил "элегантность" решения. В dismiss теперь надо передавать параметр! Т.е. это не метод конкретного экрана блокировки или его родителя. Ну и также остался вопрос, с закрытием экрана блокировки PIN/PUK, а кто для него вызвал тогда метод?! Я бы скорее подумал, что все таки dismiss грохал весь стэк. И теперь сделали, чтобы метод грохал не весь стэк а только конкретный экран, который и был разблокирован. В общем медведя на велосипеде с костылем все вспомнили
ykira
14.11.2022 12:13+2Главное чтобы новый код не грохал запрос о разблокировки второй сим-карты, или будет отговорка что у нас нету двухфизическисимочных телефонов.
На моём третьем пикселе постоянные проблемы с локскрином, то они накладываются друг на друга и нужно разблокировать несколько раз, то из-за нехватки памяти выбивает с локсрина на рабочий стол, но при открытии любого приложения снова выходит локскрин.
Protos
14.11.2022 22:15+1Где то там спряталась бага, за которую можно 70000$ получить, а вы все ее не найдёте
titbit
13.11.2022 11:03+6Мда, оказывается (кто бы мог подумать), что даже блокировке экрана доверять нельзя. Концепция стека вызовов уязвима к ошибкам или атакам состояния гонки! Злоумышленники потирают руки, ведь многие телефоны не получат исправление этой ошибки, а пользоваться ей очень легко. Интересно, есть ли шанс исправить что-либо самостоятельно, если обновление 100% не придет?
Sfinx88
13.11.2022 11:44+1Интересно, а Android устройства других изготовителей? Кто нибудь проверял?
HappyGroundhog
13.11.2022 12:02Многие мои предыдущие телефоны сразу же выключались при открытии лотка SIM.
Popadanec
13.11.2022 12:48+8Были в руках разные смартфоны. От сверхбюджетного хлама с троянами в заводской прошивке, до совсем не бюджетных(самсунг, сяоми, fly, ещё какие то уже не помню). Ни один не выключался.
RatsM
13.11.2022 14:44У меня на OnePlus 5t с последней официальной прошивкой бывает рандомно разблокируется при не до конца введенном графическом пароле
dartraiden
13.11.2022 15:55+1Я не помню свой PUK, но на всякий случай убрал запрос PIN-кода симки при запуске.
konst90
13.11.2022 17:01+6А разве это свойство телефона, а не симки? Мне кажется, что запрос PIN делается в зависимости от SIM-карты, но не телефона. И в этом случае уязвимость телефона не устранена, зато добавилась уязвимость SIM-карты.
dartraiden
13.11.2022 17:51+7Тогда дело совсем плохо и это пахнет фактически отсутствием экрана блокировки на очень большом числе устройств.
И получить за это автор мог быть не 70 тысяч долларов, а минимум на пару порядков больше, если бы обратился в конторы типа Zerodium.
PsyHaSTe
14.11.2022 19:29Не думаю, что кто угодно выплатил бы ему 7 миллионов зелененьких необеспеченных бумажек за какую угодно уязвимость 0 дня, кроме разве что "перечислить удаленно все деньги пользователя мне на криптокошель".
IgorPie
13.11.2022 18:33+2Теперь в случае утери/кражи телефона злоумышленники вашу симку воткнут в подготовленный телефон и наберут кредитов и микрокредитов + на госуслугах пошалят, т.к. там двухфакторка по смс.
Уже много лет симка ценнее телефона и пин код хоть как-то дает выиграть время.
Новая симка и пак код на непатченный телефон дадут доступ к внутреннему диску, но хотя бы банки будут в относительной безопасности
mayorovp
13.11.2022 19:08+3Не будут. Сначала запрашиваем код подтверждения на CMC, потом разблокируем телефон. Наверняка же пришедшая СМС окажется сохранённой в самом телефоне и доступна к прочтению...
dartraiden
13.11.2022 19:11+1Им придётся ещё пароль от госуслуг узнать. Именно так и работает 2FA — нужно знать оба фактора, а не только второй. Конечно, первый фактор (пароль) при этом должен быть стойким, а не 12345абвг.
К счастью, как выяснилось (найти PUK-код оказалось ещё тем квестом), мой телефон не подвержен этой уязвимости вообще.
Popadanec
13.11.2022 20:56Чтобы заново авторизоваться в приложении, нужно знать логин. Правда многие интеллектуалы логином назначают номер симки, не понимая опасности этого действия.
Dolios
14.11.2022 10:40+1Очень опрометчивое решение. Злоумышленник вставляет вашу симку к себе в телефон и получает доступ ко всем вашим деньгам в банках, потому что сейчас вся безопасность на смс завязана.
Lapland_Man
14.11.2022 11:15Не получает. Так получилось, что в этом году 3 раза менял телефон, и каждый раз квест с регистрацией
Dolios
14.11.2022 11:17+3Какой именно квест? Зная номер карты и имея рабочую симку можно получить доступ в интернет-банк большинства (если не всех) банков РФ.
Popadanec
14.11.2022 12:34+3Сейчас проверил и это действительно так. Мне без моего согласия дали возможность входить по номеру карты(хотя у меня был логин).
Раньше был только логин, который можно было получить в банкомате, а потом при желании сменить на любой.
И вход по номеру нельзя(в Сбере) отключить. Пуш вместо СМС так же не помогают.
Кто то облегчив доступ в приложение для клиентов банка, случайно или намеренно создал огромную дыру в безопасности. С учётом утечек, пары номер карты плюс номер телефона уже давно есть у всех кому надо.
Попросил ТП дать возможность отключить вход по номеру карты, оставив только логин, ответят через три дня что надумали.
Те у кого тоже Сбер, устройте им Хаброэффект пожалуйста, а то ведь отмахнутся или поставят тикет в неприоритетные.Dolios
14.11.2022 16:45+2Это о всех банках сейчас так. Банки экономят деньги, разгружают отделения от тех, кто забыл пароль и приходит его восстановить. А на риски клиентов им плевать, убытки не они же нести будут в случае чего...
Popadanec
14.11.2022 18:23Ну мне ТП только что ответили, что оценили проблему и отправили на реализацию.
Зная об этой искусственно созданной дыре, вполне вероятно выбить деньги из банка. Это не пара тысяч с карты. И угроза найма адвоката или хотя бы публикация на банки.ру, заставит их вернуть деньги.Dolios
14.11.2022 19:24Хотите пари? Я считаю, что ничего исправлено не будет и сброс пароля/доступ в интернет-банк по смс запретить будет нельзя.
Popadanec
14.11.2022 19:32+1Только заявка была составлена на галочку в настройках, чтобы нельзя было использовать вместо нормального логина, номер карты.
Я могу войти по созданному логину и по номеру карты. Т.е. фактически имею два логина и один из них известен мошенникам. Им остаётся только украсть симку и пробить по своим базам. Ни о какой безопасности речи вообще не идёт.
Ладно хоть смс банкинг удалось выключить. И то он у большинства по умолчанию включён. А это ещё большая дыра в безопасности.Dolios
14.11.2022 19:35+3Проблема не в логине и номере карты, на это наплевать. Вы свой логин от почты отдаете всем и никакой беды в этом нет.
Проблема в том, что вас либо пускают без пароля по коду из смс, либо позволяют этот самый пароль сбросить по коду из смс. И вот это беда. Это значит, что никакого пароля у вас, на самом деле, нет, а есть только 1FA — симка.
Требуется иметь возможность запретить смену или восстановление пароля по смс без визита в отделение банка с паспортом. Если бы это было, то и симку не требовалось бы так тщательно охранять и это была бы реальная 2FA, а не современная фикция.
Popadanec
14.11.2022 19:58-2Не зная логина, пароль бесполезен, т.к. доступа не получишь.
Логин можно в ЛК назначить в любой момент произвольный.
А вот номер карты можно только сменить и то платно вместе с ней.
Dolios
14.11.2022 20:00+1Логин — это не секретная информация. Секретная информация — пароль. Именно он солится, хэшируется и всячески защищается. Странно, что такие вещи приходится объяснять на хабре.
Popadanec
14.11.2022 20:02Я это прекрасно знаю. Но надежды на запрет сброса пароля или вход по смс по смс я не испытываю никаких. Потому со Сбером приходится удалять гланды через анус. И то он не факт что согласится.
Если использовать логин только в мобильной версии, то он нужен только один раз, при регистрации и в дальнейшем нигде не светится. Потому фактически может и являться паролем, а логин можно сбросить смской.
navion
14.11.2022 17:04Я попробовал включить PIN-код на симке и она заблокировалась без подтверждения, так что осторожнее с экспериментами.
А сам телефон застрял на экране ввода PUK пока не извлечёшь симку.
dartraiden
14.11.2022 17:29То, что застревает, это нормально.
Если никогда не менялся PIN симки, скорее всего, он дефолтный — 0000navion
14.11.2022 17:38Именно его я ввёл и сразу получил локскрин симки с требованием ввести правильный, то есть в симке тоже настройки меняются без проверки кода.
laminor4ik
13.11.2022 12:33+8Так как атакующий может воспользоваться собственной SIM-картой с блокировкой PIN-кодом, для эксплойта этого бага не нужно ничего, кроме физического доступа. Атакующий может просто заменить SIM в устройстве жертвы, выполнить эксплойт с SIM-картой, имеющей блокировку PIN-кодом, для которой у атакующего есть PUK-код.
Я перестал верить в серьезную целесообразность использования pin-кода на сим-картах. Как-то тоже забыл пин от симки, а пук-кода под рукой не оказалось. Позвонил оператору, спросил про восстановление пука, и мне его озвучили, даже не спросив паспортных данных ????♂️
Решил провести процедуру на второй симке с другим оператором. Второй оператор уже попросил серию и номер паспорта. Однако, если злоумышленник захочет добраться до моей симки, скорее всего у него эта инфа уже будет, и он тоже спокойно восстановит пук-код.
Короче говоря, пин-код на симке можно юзать разве что от детей ????♂️
Pokolo
13.11.2022 13:08при этом на симку завязано столько всего от банка до госуслуг, так что храню симку дома в сейфе. пин код всё равно надо поставить.
Ionenice
13.11.2022 13:46+21А оператор берёт и перевыпускает симку)
leotsarev
13.11.2022 22:59После перевыпуска симки у тебя сутки не ходят SMS (Мегафон)
NNikolay
14.11.2022 04:49+5Но как узнать об этом если симка в сейфе?
Ainvain
14.11.2022 07:05По крайней мере банки по какой-то схеме получают от оператора инфу о смене IMSI по номеру, и блокируют операции.
Popadanec
14.11.2022 12:43Блокируют лишь временно.
Вот у Сбер бизнес, перевыпуск симки ничего не даст, без похода в банк с подтверждением личности и операции.
Почему нельзя распространить это и на физиков, я не знаю, хоть это вызовет некоторые неудобства. Но могли бы дать возможность хотя бы опционально.Dolios
14.11.2022 16:47+1Почему нельзя распространить это и на физиков, я не знаю, хоть это вызовет некоторые неудобства. Но могли бы дать возможность хотя бы опционально.
Потому что это доп расходы, которые банки не хотят нести.
Popadanec
14.11.2022 18:24Это скорее дэффективный менеджмент. Потому что экономя на одном, они теряют в другом.
dartraiden
13.11.2022 15:46+2Короче говоря, пин-код на симке можно юзать разве что от детей ????♂️
Вы упустили сценарий «кто-то украл телефон / нашёл мой потерянный телефон и решил поживиться».
В этом случае нашедший не сможет ни воспользоваться симкой, ни восстановить PUK (он номера телефона не знает).
screwer
13.11.2022 16:43Достаточно сделать удалённую перезагрузку (ну или надеяться что телефон сам отрубится выбрав батарею). На холодном старте метод не сработает.
navion
15.11.2022 17:08От этого сценария могла бы спасти eSIM, но из-за дыры она даже хуже обычной симки с пином.
Vilgelm
13.11.2022 14:53+3Кто-то уже проверил работает ли это на вашем Xiaomi, Samsung и так далее?
dartraiden
13.11.2022 18:54+1Лень искать в гите, в какой версии эта уязвимость появилась, но Яндекс.телефон с Android 9 не подвержен (а Яндекс явно не менял исходники Android так глубоко, как, например, Xiaomi).
Bedal
13.11.2022 15:19+1Кстати, если на самсунгах на двойное нажатие кнопки включения повесить камеру, то после её появления можно платить - не разблокируя телефон. Но дыры вроде в этом нет, потому что так проходят только мелкие платежи, и разблокировки, на самом деле, не происходит.
Зато - удобно, можно контролировать, что там пишет терминал, на экране камеры.
jaiprakash
13.11.2022 15:52А мелкие платежи это сколько? И что мешает сделать много мелких?
Bedal
13.11.2022 23:37@Popadanecуже ответил. Да, мелкие - это 1 тыр. Хотя на заправке луйкойла и 3 тыра без вопросов снимается, так что смотря где платить.
konst90
13.11.2022 17:05Это можно делать и без камеры. Достаточно просто включить экран кнопкой включения, и NFC-модуль активируется. И точно так же, как обычной картой с NFC можно платить до определённой суммы без PIN, так же можно и с телефоном без разблокировки. А при сумме выше порога будет запрошена разблокировка.
Так что это вообще не дыра.
UPD. Об этом прямо в справке Google Pay написано:
В каких случаях для оплаты не нужно снимать блокировку экрана
Важно! Количество транзакций при заблокированном экране ограничено.
Обычно для совершения бесконтактных платежей нужно снимать блокировку экрана. Исключение составляют случаи, когда сумма покупки незначительна.
https://support.google.com/pay/answer/7644132?hl=ru&ref_topic=7625138
Popadanec
13.11.2022 21:01Я несколько раз пробовал просто включать экран без разблокировки, ни разу не срабатывало. Гугл Пэй, суммы 100-200-300р.
Bedal
13.11.2022 23:37а попробуй камеру включить :-)
Popadanec
14.11.2022 11:45Смысла нет. У меня кнопка включения совмещена со сканером отпечатков пальцев(m31s) и проще разблокировать и тут же заблокировать. Считывание отпечатка всегда с первого раза. Но я использую не подушечку большого пальца, а её боковую часть. Она уже естественно ложится на кнопку и надо постараться, чтобы не разблокировать устройство. Раньше использовал центр подушечки, но она то мокрая, то повреждена, то просто со временем переставал считываться.
Bedal
14.11.2022 12:39У меня кнопка включения совмещена со сканером отпечатков пальцев
а, ну так-то да. А у меня новомодный сканер под экраном. К превеликому сожалению.
Bedal
13.11.2022 23:40Это можно делать и без камеры. Достаточно просто включить экран кнопкой включения, и NFC-модуль активируется.
В моём случае без камеры, просто включить экран - не срабатывает. Mir Pay на Samsung A70. Впрочем, и раньше с Google Pay было аналогично.
Так что это вообще не дыра.
Я и не жалуюсь - очень уж больших сумм там не держу, зато очень удобно, не надо палец облизывать (когда руки сухие, отпечаток пальца не распознаётся).
pavelsc
13.11.2022 15:52-4Хотите ещё сотку заработать? Поднимаете в домашней вайфай сети сервер обновлений андроид и туда выкладываете патч с ревертом коммита этого ????
Классная идея для подвала в застенках АНБ
dartraiden
13.11.2022 15:59+3Смешная шутка, осталось только ключ у Google добыть, которым они подписывают прошивку.
Maccimo
13.11.2022 16:58+22я начал по-настоящему переживать
…
Это было пугающе странно.
…
У меня начали трястись руки.
…
Это событие привело меня в ужас.До чего же впечатлительный хацкер пошёл. Эдак его однажды Кондратий хватит.
Boilerplate
13.11.2022 17:42+3Вообще все формулировки выглядят так, чтобы показать, что он "очень переживал за безопасность" и "делал все возможное, чтобы исправили быстрее". Правда, когда ему пообещали 70к заплатить обратно, пыл поубавился. И чтобы это не выглядело как вымогательство, то все обернуто в беспокойство. Но тут его позиция абсолютно правильная - такое надо и исправлять быстрее, и платить деньги сообщившему, а не разводить бюрократическое болото.
lamerok
13.11.2022 17:54+6Статья занимательная, правильно я понимаю, что первым кто знал о проблеме были сотрудники ФБР, поэтому и поставили статус, что проблема известна
Maccimo
13.11.2022 17:58+5выполнил горячую замену из лотка SIM-карты
Теоретически эта бага могла затаиться со времён, когда SIM-слот располагался под съёмной батареей и случайно обнаружить багу было затруднительно. Ну, а люди с тайным знанием могли позаботиться о том, что мобила не обесточится при вынимании батареи.
kisskin
13.11.2022 19:32Занятно, но идея уязвимости лежала на поверхности - старые кнопочные телефоны примерно так и разблокировались через другую симку, т.к. каких-то ценных данных тогда на телефонах не было. С тех пор всё поменялось, но старый принцип работы оставался ещё долго
Popadanec
13.11.2022 21:03+1Т.е. дыра ещё с кнопочников. Тогда это не уязвимость, а оставленный бэкдор.
konst90
13.11.2022 21:27+4Дыра подразумевает наличие системы защиты. А там, как правило, её не было как класс - сам аппарат в принципе не защищался от использования в чужих руках. Вынул симку, поставил другую - пользуйся.
K0styan
14.11.2022 10:27+1Оффтоп. Пересматривал не так давно фильм "Враг государства" 1998 года, один момент умилил особенно. Главного героя там по сюжету ставит под наблюдение АНБ - вот буквально влезая домой и утыкивая всё жучками. С мобильником же поступает того проще - его не вскрывают и не припаивают ничего, банально подменяют на свой, уже, надо думать, пропатченный. Разумеется, владелец подмены не замечает.
То есть персонализации на уровне девайса - вообще ноль.
eurol
14.11.2022 12:44Ой, не скажите. Была привязка телефона к симке. Меняешь симку - надо ввести код телефона. И через несколько неудачных попыток телефон превращается в тыкву.
AlexeyK77
14.11.2022 00:04-1Во всех больших организациях развита в первую очередь бухгалтерия и бюрократический бизнес-процесс вокруг траты денег. Если бы автор выявления бага был по-настоящему не первым, а вторым, как заявлял вначале гугл, то ему бы никогда не выплатили вознаграждение, чисто по процедурно-бухгалтерским причинам. Уж чего-чего, а денежку там считать умеют, иначе бы не выросли до монополиста.
А раз выплатили, значит все-таки он был первый, просто багу морозили или зажимали денег.
Ztare
14.11.2022 12:45+1Выходит все экраны блокировки это ширмочки, которые при закрытии(падении?) пускают в систему? По идее под этими экранами ничего не должно быть доступно, пока хеш пароля введенного не отдан глубже в ядро от каждого экрана. Детский сад
wepp
14.11.2022 13:07Так и есть. Возился с простеньким Самсунгом у тёщи, не могли войти в систему. Обход производился через спаривание с блюпук-колонкой и быстрым нажатием на экран (ловилось окно с настройками).
Revertis
14.11.2022 15:30+1Проблема позволяла атакующему с физическим доступом к телефону обойти меры защиты экрана блокировки (отпечаток пальца, PIN и так далее), получив полный доступ к устройству пользователя.
А разве PIN/графический узор и пароль не используются при шифровании раздела с данными? Вроде всегда было так.
K0styan
14.11.2022 17:40Насколько я понимаю, первый ввод пароля после включения аппарата действительно расшифровывает раздел - и именно поэтому первый логин проводится не с биометрией, а строго с пином/узором. А вот потом ключ висит в ОЗУ, и при блокировке не стирается.
Revertis
14.11.2022 21:59А насколько я понял, как раз раздел у него расшифровывался. Иначе с чего такие судороги?
PsyHaSTe
14.11.2022 19:36Немного оффтопика: есть старый сяоми, с графическим ключом который забыли, на нем видео и фото которые хочется стянуть. По ЮСБ без анлока телефона скачать не дает.
Как быть в такой ситуации? Планирую попробовать этот эксплоит, но если не сработает то есть ли способ данные восстановить?
Pornopatsan
15.11.2022 15:09+2Мой испорченный мозг прочитал название статьи: "Как я случайно обошёл блокировку Google Pixel и получил за это штраф $70 тысяч"
alekssamos
15.11.2022 17:51Сразу вспомнил одну из своих первых программ, тоже для блокировки, компьютера, правда.
Просто окно на весь экран, которое нельзя свернуть и закрыть.
Но через несколько минут я понял, что это ни какая не защита.
nimishin
Классная статья)) каждый мечтал бы найти такой баг
codecity
Только нам бы не выплатили - нужно не только найти но и добиться. Как вы проверите повторный это баг или нет? На любой смогут написать что повтор и перемножить на 0.
dartraiden
Не выплатила бы Google, выплатила бы Zerodium и похожие конторы.
Если этот баг присутствует на большинстве устройств, то это просто праздник для атакующего.
codecity
Но там наверняка не $100 тыс.?
SnikeMK
Зато больше, чем 0$
svosin
Именно столько. http://zerodium.com/program.html
acsent1
Ему выплатили только потому что он лично на конференции еще раз подошел с разрабам с этим багом.
А про "ваш баг - это дубль" - полно статей
ssj100
может там 50% рандом вызывает функцию ne_liubliu_neudachnikov() с шаблом "это дубль"
anokhinpa
В текущих реалиях есть и другие причины для отказов в выплатах.
Мне посчастливилось около полугода назад найти баг в приложении exodus для криптокошельков с обходом пароля. Это вышло случайно и я долгое время не мог его воспроизвести
Но пару месяцев назад я снова случайно смог войти в приложение без ввода пароля и решил разобраться. Смог воспроизвести его несколько раз, после чего завел тикет на hackerone, благо exodus там есть
После разбирательств мы договорились о выплате 1000$ в качестве вознаграждения и они перевели мне деньги на счет внутри системы
Только вот вывести эти деньги я не смог из-за санкций. Что ещё глупо, так это то, что и украинцы сталкиваются с такой же проблемой, а из саппорт просто не отвечает на мои вопросы
Понятно, что это перевод и автор оригинальной статьи не столкнулся бы с такой проблемой. Просто вспомнил свой «удачный» кейс)
codecity
В какой валюте выплатили? Перевести то на кошелек вы можете? Можно ведь через отечественные биржи вывести, та же indx.
ne555
Важное дополнение, для тех, кто без обновлений, если у вас отжали телефон, то:
ИМХО, 70к зелёных шуршунчиков — невысокая награда для уязвимости, которая таилась на протяжении многих релизов OS. Не исключаю, что это был взаимовыгодный бэкдор (вспомним разоблачения от Э. Сноудена и еще более громкое: "Убежище 7").
lopatoid
Только в "Убежище 7" и прочих слитых документах ничего нет про то что в какие-то продукты специально добавляли бэкдоры, так что эти документы, наоборот, убеждают нас в маловероятности "взаимовыгодного бэкдора". Если уж даже в слитых документах про существование бэкдоров для спецслужб ничего не было, то уж совсем это слабенькая версия.
ne555
Ничего не было, потому что в слитых, опубликованных доках путного особо не было. "Интересное", возможно, очистили перед выгрузкой для масс. В "убежище 7" половина/больше сырых документов полностью пустые, имеют только имя/дату. Как сообщали в Викиликс: зачистили намеренно.
Hidden text
По Сноудену, сливы его не изучал, но СМИ сообщали, что Гугл в т.ч. сотрудничает со спецслужбами.
В прошлом:
Я тоже подтверждаю и бэкдор и не связанный с ним взлом. У меня была на руках и рутованная и обычная одна из упомянутых привлекательных по цене Китайских моделей гаджета, в одной из своих статей я упоминаю эту модель.
И до Сноудена шум поднимали.
Если что, я не утверждаю о намеренном черном ходе, это всего лишь мои домыслы на основе анализируемой информации.
lopatoid
>Как сообщали в Викиликс: зачистили намеренно
С таким подходом может и всё остальное в этих сливах отредактировано, зачищено, или даже выдумано с нуля.
>это всего лишь мои домыслы на основе анализируемой информации.
Да вот я на Хабре уже 12 лет, буквально под каждой новостью об очередной уязвимости обязательно кто-нибудь напишет, что это "бэкдор от CIA/FBI/NSA/NBA/TLA". Плюсики такие комменты каждый раз стабильно собирают, только ни разу такие теории не получили ни подтверждения, ни каких-то доказательств.
ne555
Вон оно в чём дело, в плюсиках.
Какие-то были.
Предподожит? Что в этом плохого?
Если я своими собственными глазами видел и бэкдор и взлом китайского гаджета. Нормальная реакция сомневаться в некоторых продуктах после такого.
shasoftX
Так точно также в каждой новости про яндекс колонки и яндекс ТВ пишут про "товарища майора".
lopatoid
Ну всё-таки есть разница между инсинуациями и простым напоминанием российских законов.
gxcreator
А в какой стране частные компании не обязаны передавать данные силовикам?
Quark-Fusion
вызывать dismiss для непонятно какого в текущий момент экрана — это не бэкдор, а халатность, сама концепция в корне неверная, что если в текущий момент экран другой? это же никто не проверяет, а что если dismiss был вызван по ошибке? по-хорошему при вызове функции снятия блокировки нужно передать код разблокировки, который функция и сверит с требуемым кодом, тогда в случае ошибки экрана или отсутствия введённого кода система не разблокируется
SeregaSA73
Ну так на фотке кто изображен, что вы хотите от них что бы они сидели и вдумчиво подходили к решению задач, раз-два и в продакшн.
Ivan22
да, да. При нокиа такой х..ни не было
singalen
Очаровательно. Расистский комментарий от человека, который не факт, что имеет даже отдалённое представление о сложности описываемой системы.
Firsto
Помнится одна история с заблокированной моторолой, где удавалось попасть на домашний экран через справочный модуль.
Вкратце: из ввода кода можно было открыть экран восстановления через гуглоакк, на форме ввода вызвать неподдерживаемые клавиатурой языки, попытаться добавить какой-нибудь хинди, где выпадало вебвью с ошибкой, откуда можно было вызвать систему печати и перейти в настройки, в которых удалить гуглоакк, после чего девайс зависал на пару минут, падал с перезагрузкой интерфейса и показывал рабочий стол.
Ну а дальше подключение через adb, разрешение на отладку, и поехали...
QDeathNick
В какой-то старой винде типа 95, тоже можно было открыть справку с экрана авторизации.
mayorovp
В какой-то старой винде типа 95 "экран авторизации" (на самом деле — окно выбора профиля) чуть ли не кнопкой "отмена" закрывался