Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 100К мы не доберем, но проверить эту историю реально.
Просто странно, что это в таком случае не указано в их политике. Было бы написано, вопросов бы вообще не было.
Я и сам считаю, что это не задача магазинов - в обязательном порядке проверять все приложения на уязвимости, это весьма трудоемко и сложно, учитывая и объемы и разнообразие технологий даже в мобилках. Но если уж ты об этом заявляешь - делай это хорошо =)
Да, есть такие планы, но пока что приложение в разработке. Да и немного труднее там получить сертификат разработчика и пройти формальные процедуры. Но мы справимся.
К сожалению, не большой в этом эксперт, но на самом деле такие проверки вполне могут иметь неплохой шанс обнаружить что-то нехорошее на устройстве. Как минимум по известным сигнатурам проанализировать apk-файлы, которые установлены очень даже возможно. Они как раз лежат в директории, к которой есть доступ у всех приложений, поэтому спокойно можно их посмотреть и сравнить (некоторый аналог VirusTotal).
Более продвинутые приложения такого рода умеют анализировать намного больше вещей, которые косвенно могут означать наличие проблем. Так что я бы не преуменьшал их значимости, проверяют что-то и хорошо, какой-то вектор закрывают. Но и рассчитывать только на них, конечно же не стоит.
Хорошая идея, попробуем чуть попозже в гугл и остальные магазины направить репорт о том, сколько всего мы в своем приложении нашли, действительно интересно, как они отреагируют, может даже небольшое продолжение напишем.
Согласен, в Android, особенно в версиях с 11-го, весьма неплохо Google постарался. Но речь все-таки больше про ошибки, которые допускаются на уровне приложений, которые некоторые магазины обещают проверять. Тут, сколько приложения не зажимай в правах, а такие проблемы все равно будут.
И я как раз хотел показать, что нельзя надеяться на такого рода проверки и что за безопасностью надо в первую очередь следить самим.
А можно плз подробнее? Про "взлом" icloud я читал только в контексте соц.инжиниринга/фишинга/итп. Подбор пароля локального бэкапа? Ну удачи :)
Компания ElcomSoft как раз занимается разработкой инструментов для форензики, в том числе инструментами для подбора пароля от локальных/облачных бэкапов (с применением GPU и прочих радостей). Ну и вытаскивание данных из iCloud.
Ну и другие продукты для форензики мобильных телефонов тоже так умеют, просто я работал только с ElcomSoft.
Насколько помню, доступ даже к локальному средствами OS завязан на залогиненом юзере. Можно вытащить сам файл, но все интересное в нем зашифровано.
А нам сам файл не нужен, мы от имени приложения "легально" можем обратиться к хранилищу. Я выше описывал примеры, как это можно сделать, используя туже самую Frida. Да, это требует JailBreak, но это вполне возможно.
На локальные бэкапы можно ставить отдельный пароль.
Я это и имел ввиду, да. Пароль пользователя не от устройства, а тот, что он задает при создании бэкапа, возможно не так выразился.
Можно же тупо подменить прикладной/системный софт, который легально взаимодействует с шифрованным хранилищем.
Ну вот для Security Enclave пока ничего подобного не придумали. Это отдельный сопроцессор для выполнения различных операций, связанных с безопасностью и шифрованием данных. Весьма занятная штука, но я редко встречаю его использование в приложениях.
На старых устройствах и версиях ОС можно встретить много дичи :)
Это точно)) Но в основном на данный момент это iOS 14 и постепенно переходим на 15
Это вопросы исключительно к кривизне рук разраба этого приложения.
Абсолютно согласен. Но ведь и поведение системы весьма странное, удаляем файлы, но оставляем данные в KeyChain...
Так пароли в открытом доступе то нигде и не лежат. Вообще, вопросы безопасности — они на совести пользователя. Если отключить 2FA и поставить пароль вида "123", то можно не удивляться последствиям :)
Ну не в открытом доступе, да) Но в открытом виде (plaintext), тоже так себе. Конечно, пользователь сам себе злой буратино, но в интересах разработчика (или безопасника) попробовать сделать приложение более безопасным. Ну или хотя бы усложнить путь для выстрела себе в ногу.
Как говорил один мой знакомый — самый безопасный компьютер — отключенный от сети питания и помещенный в сейф.
Именно так! А самый безопасный код - который не работает! :)
Все разы когда я пытался сделать полный бэкап андроид аппарата (разных производителей), данные приложений не попадали в него.
А, я немного не понял вопроса просто. Да, в Android возможно сделать бэкап конкретного приложения со всеми его файлами, если разработчик это не запретил (а может и вообще переопределил в коде поведение при бэкапе). При бэкапе устройства - это системные штуки.
В iOS же, вроде бы, нельзя сделать бэкап конкретного приложения, но при полном бэкапе устройства в него попадают файлы приложений, а если он зашифрован, то и данные KeyChain.
Перед ответом на конкретные вопросы отвечу - да, действительно многие вещи шифруются. И KeyChain и локальные бэкапы и многое другое защищается при помощи различных ключей, их комбинаций и производных от пароля пользователя. Но с другой стороны, есть и инструменты, которые позволяют подобрать пароли и от учетных записей iCLoud и от локальных бэкапов (используя всю мощь GPU). Так что то, как именно защищать и какие именно данные защищать дополнительным шифрованием зависит целиком от компании и их моделей угроз и злоумышленника. Как говорится необходимо сделать взлом приложения экономически невыгодным для злоумышленника, чтобы он потратил сильно больше времени и ресурсов на получение информации из приложения по сравнению с затратами, которые он на это дело положит.
Подождите, но ведь содержимое keychain шифруется? И дешифруется (и то, не все сразу) только при некоторых условиях.
Действительно, KeyChain представляет собой SQLite-базу данных на устройстве, часть информации в которой зашифрована. Доступ к элементам KeyChain имеет только приложение, которое ее туда записало или же приложения, объявленные в настройке KeyChain-access-groups. Получить доступ к данным в KeyChain можно в зависимости от флага доступа, с которым они были записаны (например, AccessableAfterFirstUnlock, при котором данные могут быть получены в любой момент после первой разблокировки устройства и т.д.).
Но опять, способов получения данных из KeyChain несколько, как минимум, насколько мне известно, это динамическая инструментация приложения (при помощи Frida, к примеру) и обращение к данным напрямую из контекста приложения (в общем случае требуется наличие JailBreak). И второе - это возможность получения данных из зашифрованного локального бэкапа (при чем только данных, сохраненных с атрибутом доступа без постфикса ThisDeviceOnly). Клнечно, вектор атаки на эти данные весьма узкий, но в любом случае его не нужно сбрасывать со счетов. И все равно, сохранять данные пользователя plaintext`ом даже в системном хранилище это плохая идея. Это к слову об описанном мной случае излишнего доверия операционной системе. Ну и не зря же придумали Security Enclave, который позволяет хранить и шифровать данные действительно безопасно. Ведь к этому был какой-то тригер.
Бэкапы же тоже шифруются?
Да, бэкапы шифруются на пароле пользователя (если такая настройка была задана при создании бэкапа). При этом, если зашифрованная копия никогда не создавалась, пользователю необходимо задать пароль самостоятельно. А ведь, как нам известно, по статистике (по данным Avast за 2020 год) более 50% Россиян используют одинаковые пароли от разных сервисов. А во вторых, если никогда не создавалась резервная копия, то злоумышленник может самостоятельно задать свой собственный пароль и без труда получить все необходимые данные.
Да, снова вектор угрозы невелик, но защитить данные пользователя от попадания в бэкап это тоже хорошая идея.
А при наличии Jailbreak, в принципе, можно забыть про бОльшую часть защиты. Аналог — получение рута на андроиде через патчер от Васяна с 4pda.
Ну вот тут я не соглашусь. Условно, если мы ничего не храним в открытом виде ни на файловой системе, ни в KeyChain, ни где-бы то ни было еще, то особой пользы злоумышленник с Jail для себя не вынесет. А если в нашем приложении реализована проверка на наличие JailBreak, то ее еще надо обойти (да, конечно, это в большинстве случаев просто сделать, но бывают и приятные исключения). То есть тут опять путь "повышения цены" получения каких-либо данных с нашего приложения и ценность этих данных по сравнению с ценой атаки.
Но как? Keychain привязан к apple id.
Отвечу на самом деле историей из жизни. Я по долгу службы часто работаю с Б/У устройствами и некоторые из них покупаю с рук. На части устройств (особенно если закупаешь массово), бывают остаются привязки к прошлым Apple ID. Такие устройства мы тоже проводим через процедуру Jailbreak, и каково было мое удивление, когда при тестировании очередного приложения и его установке, вместо стандартного welcome-экрана приложения я увидел экран с вводом пин-кода. Ну а заглянув в Keychain я нашел и тот самый пин. В результате я попал в личный кабинет человека практически не предпринимая никаких действий.
А этому есть несколько причин:
Перед продажей человек не выполнил отвязку от своего аккаунта
Приложение не осуществляло очистку KeyChain
Хранение пин-кода в открытом виде.
Да, случай редкий, мало кто так делает, но я лично столкнулся с подобным, а значит и кто-то другой может.
И в конце, если подвести итог, то конечно, возможностей по получению доступа к данным приложения в iOS существенно меньше, чем в Android, но и их нельзя сбрасывать со счетов. Какие бы средства не предоставляла операционная система, но даже с их помощью хранить в открытом виде где-бы то ни было пин-код или пароль пользователя это моветон.
Спасибо большое за вопросы и комментарии! Попробую ниже свою точку зрения на это объяснить.
Можно отключить, и иметь локальные независимые копии.
Можно конечно. Но на мой личный взгляд, тут стоит смотреть на процент людей, которые про эту функциональность знают, и которые ее отключают. Лично я, зная нюансы и особенности использования этого механизма оставил его включенным, потому что удобно же! Ну правда, мой внутренний безопасник спасовал перед удобством использования экосистемы.
А тех, кто вообще об этом задумывается, как мне кажется весьма мало. Это как с китайскими устройствами на подобии Xiaomi, которая передает на свои сервера просто какое-то совсем непотребное количество телеметрии с устройства и на некоторых форумах есть целый ряд способов отключит или заблокировать этот функционал. Но сколько людей об этом задумываются и сколько из них предпринимают попытки это исправить? Не думаю, что в общем масштабе это количество имеет хоть сколько значимую цифру. Так и со всеми "удобствами" от экосистемы Apple, с одной стороны удобно, с другой может быть потенциальный вектор угрозы.
Шифрование. Я об этом ниже написал.
В комментарии ниже отвечу.
Есть. Хотя, возможно, я тут не так понял. Вы про бэкап всей системы, или данных конкретного приложения при создании бэкапа?
Я про бэкап данных конкретного приложения при создании общего бэкапа устройства. Насколько я знаю, в iOS при создании зашифрованного на пароле пользователя бэкапа системы в него попадают данные приложений (KeyChain и файловая система в том числе). В случае с KeyChain, если задать правильный атрибут доступности при сохранении данных (с постфиксом ThisDeviceOnly), то в бэкап попадет значение, зашифрованное дополнительно на ключе UID и расшифровать его можно будет только на этом же самом самом устройстве и из бэкапа уже вытащить его не получится (вернее получится, но расшифровать будет проблематично).
Что касается файловой системы, то при создании файла и записи в него информаци возможно выставить атрибут, запрещающий попадание файла в локальный/облачный бэкап. Но делать это необходимо для каждого файла/директории отдельно.
Если я не прав и можно выставить некоторый "глобальный" атрибут у всего приложения, который бы запрещал бэкапы любых файлов (по аналогии с Android'овским allowBackup), я бы с удовольствием про это почитал! Возможно, я уже отстал и такой функционал появился, буду рад быть неправым :)
Легко включается/отключается в настройках.
На самом деле аналогично пункту про синхронизацию KeyChain. Сколько людей об этом задумываются и сколько отключают.
Но и про приватность буфера обмена тоже много веселых историй на самом деле. В случае с iOS всегда было более-менее пристойно, а вот Android только с недавних версий разрешил доступ к Clipboard только приложениям, находящимся на переднем плане и активным в данный момент. До этого любое приложение могло получить доступ к буферы и считать/перезаписать в нем данные. Был случай веселого приложения, которое мониторило буфер обмена и при появлении в нем строки, попадающей под номер криптокошелька заменяло его на номер кошелька злоумышленника.
Посмотрел ваше исследование, явно не увидел, но, похоже, что оно только для Android-приложений. iOS - все хорошо или вы просто не исследовали яблочную безопасность?
В рамках прошлого года мы действительно не рассматривали iOS-приложения, а делали исследования исключительно для Android-приложений. В этом году мы обязательно исправим эту несправедливость.
А вот подобное исследование по Apple было бы очень интересным, а то есть у некоторых вера в непогрешимость яблок. На сколько она обоснована?
Ох, это очень большой вопрос, на самом деле и очень сложный. На мой личный взгляд вся "непогрешимость" яблочных приложений основана на двух больших "китах" - это закрытая экосистема (закрытое приватное API, отсутствие исходного кода, максимальное скрытие деталей в документации и патентах) и очень сильно ограниченное взаимодействие приложений друг с другом. Это делает более сложным исследования, поиск уязвимостей и понимание того, как внутри устроена система.
С другой стороны у Apple есть уникальные вектора угроз, которые специфичны только для их экосистемы. Это и облачная синхронизация KeyChain для нескольких устройств с одним AppleId, и локальные/облачные бэкапы (если в Android разработчик может прямо запретить создавать бэкап, то в iOS подобного нет), и общий буфер обмена между устройствами и отсутствие очистки KeyChain при удалении приложения и много-много других нюансов, которые делают исследование iOS-приложений крайне увлекательным занятием.
Да, не очень очевидно получилось, приношу извинения. Я имел ввиду, что поддельное приложение было для Android, а учитывая популярность официального приложения (которое изначально было только под iOS), можно представить, сколько раз установили "фальшивку" для Android.
В iOS приложения не могут залезать в другие приложения за данными, на сколько я знаю.
Насколько мне известно это действительно так, в iOS нет такого же функционала, как в Android. К примеру различных экспортируемых компонентов и намного меньше возможностей для межпроцессного взаимодействия. Но вроде бы способы есть, просто я еще не дошел в своих исследованиях до этой части.
Приложения же обмениваются каким-то образом файлами для прикрепления их в почтовых клиентах или отправке через мессенджеры. Я обязательо вернусь к этой теме, когда соберу больше информации о внутреннем устройстве межпроцессного взаимодействия в iOS.
Тут играет роль и монополия несомненно и несоразмерный уровень штрафов. Но тем не менее, даже монополисты посыпали голову пеплом после произошедшего. Думаю внутри тоже немало изменений должно было произойти. Ведь это может отражаться не только на имидже компании, но и на акциях, если компания публичная (кстати интересно посмотреть, была ли какая-то корреляция цены акций и информации по утечкам).
Если будет что-то вроде GDPR, когда суммы за утечки персональных данных космические, тогда и монополистам придется об этом задуматься серьезно.
Полностью согласен, поэтому и написал эту статью, так как мне показалось, что данная атака была недостаточно раскрыта и недооценена.
Или комьюнити или инструмент, который по SBOM позволит сказать, какие проблемные компоненты есть в приложении.
Как минимум для мобильных приложений мы уже выпустили подобный функционал. Думаю, что и для Java появится в скором времени что-то подобное.
Думаю что поправят. Скорее всего добавили на скорую руку для быстроты.
Но да, информация предоставлена не лучшим образом, сходу не разберешься.
Полностью согласен.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
молодцы они, быстро сориентировались :)
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
И это для мобильных приложений.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Спасибо!
Добрый день!
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Интересная мысль, спасибо!
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 100К мы не доберем, но проверить эту историю реально.
Спасибо!
Уверен, что так оно и есть на самом деле.
Просто странно, что это в таком случае не указано в их политике. Было бы написано, вопросов бы вообще не было.
Я и сам считаю, что это не задача магазинов - в обязательном порядке проверять все приложения на уязвимости, это весьма трудоемко и сложно, учитывая и объемы и разнообразие технологий даже в мобилках. Но если уж ты об этом заявляешь - делай это хорошо =)
Здравствуйте!
Да, есть такие планы, но пока что приложение в разработке. Да и немного труднее там получить сертификат разработчика и пройти формальные процедуры. Но мы справимся.
Здравствуйте!
К сожалению, не большой в этом эксперт, но на самом деле такие проверки вполне могут иметь неплохой шанс обнаружить что-то нехорошее на устройстве. Как минимум по известным сигнатурам проанализировать apk-файлы, которые установлены очень даже возможно. Они как раз лежат в директории, к которой есть доступ у всех приложений, поэтому спокойно можно их посмотреть и сравнить (некоторый аналог VirusTotal).
Более продвинутые приложения такого рода умеют анализировать намного больше вещей, которые косвенно могут означать наличие проблем. Так что я бы не преуменьшал их значимости, проверяют что-то и хорошо, какой-то вектор закрывают. Но и рассчитывать только на них, конечно же не стоит.
Здравствуйте!
Хорошая идея, попробуем чуть попозже в гугл и остальные магазины направить репорт о том, сколько всего мы в своем приложении нашли, действительно интересно, как они отреагируют, может даже небольшое продолжение напишем.
Здравствуйте!
Согласен, в Android, особенно в версиях с 11-го, весьма неплохо Google постарался. Но речь все-таки больше про ошибки, которые допускаются на уровне приложений, которые некоторые магазины обещают проверять. Тут, сколько приложения не зажимай в правах, а такие проблемы все равно будут.
И я как раз хотел показать, что нельзя надеяться на такого рода проверки и что за безопасностью надо в первую очередь следить самим.
Компания ElcomSoft как раз занимается разработкой инструментов для форензики, в том числе инструментами для подбора пароля от локальных/облачных бэкапов (с применением GPU и прочих радостей). Ну и вытаскивание данных из iCloud.
Ну и другие продукты для форензики мобильных телефонов тоже так умеют, просто я работал только с ElcomSoft.
А нам сам файл не нужен, мы от имени приложения "легально" можем обратиться к хранилищу. Я выше описывал примеры, как это можно сделать, используя туже самую Frida. Да, это требует JailBreak, но это вполне возможно.
Я это и имел ввиду, да. Пароль пользователя не от устройства, а тот, что он задает при создании бэкапа, возможно не так выразился.
Ну вот для Security Enclave пока ничего подобного не придумали. Это отдельный сопроцессор для выполнения различных операций, связанных с безопасностью и шифрованием данных. Весьма занятная штука, но я редко встречаю его использование в приложениях.
Это точно)) Но в основном на данный момент это iOS 14 и постепенно переходим на 15
Абсолютно согласен. Но ведь и поведение системы весьма странное, удаляем файлы, но оставляем данные в KeyChain...
Ну не в открытом доступе, да) Но в открытом виде (plaintext), тоже так себе. Конечно, пользователь сам себе злой буратино, но в интересах разработчика (или безопасника) попробовать сделать приложение более безопасным. Ну или хотя бы усложнить путь для выстрела себе в ногу.
Именно так! А самый безопасный код - который не работает! :)
А, я немного не понял вопроса просто. Да, в Android возможно сделать бэкап конкретного приложения со всеми его файлами, если разработчик это не запретил (а может и вообще переопределил в коде поведение при бэкапе). При бэкапе устройства - это системные штуки.
В iOS же, вроде бы, нельзя сделать бэкап конкретного приложения, но при полном бэкапе устройства в него попадают файлы приложений, а если он зашифрован, то и данные KeyChain.
И снова спасибо! :)
Перед ответом на конкретные вопросы отвечу - да, действительно многие вещи шифруются. И KeyChain и локальные бэкапы и многое другое защищается при помощи различных ключей, их комбинаций и производных от пароля пользователя. Но с другой стороны, есть и инструменты, которые позволяют подобрать пароли и от учетных записей iCLoud и от локальных бэкапов (используя всю мощь GPU). Так что то, как именно защищать и какие именно данные защищать дополнительным шифрованием зависит целиком от компании и их моделей угроз и злоумышленника. Как говорится необходимо сделать взлом приложения экономически невыгодным для злоумышленника, чтобы он потратил сильно больше времени и ресурсов на получение информации из приложения по сравнению с затратами, которые он на это дело положит.
Действительно, KeyChain представляет собой SQLite-базу данных на устройстве, часть информации в которой зашифрована. Доступ к элементам KeyChain имеет только приложение, которое ее туда записало или же приложения, объявленные в настройке KeyChain-access-groups. Получить доступ к данным в KeyChain можно в зависимости от флага доступа, с которым они были записаны (например, AccessableAfterFirstUnlock, при котором данные могут быть получены в любой момент после первой разблокировки устройства и т.д.).
Но опять, способов получения данных из KeyChain несколько, как минимум, насколько мне известно, это динамическая инструментация приложения (при помощи Frida, к примеру) и обращение к данным напрямую из контекста приложения (в общем случае требуется наличие JailBreak). И второе - это возможность получения данных из зашифрованного локального бэкапа (при чем только данных, сохраненных с атрибутом доступа без постфикса ThisDeviceOnly). Клнечно, вектор атаки на эти данные весьма узкий, но в любом случае его не нужно сбрасывать со счетов. И все равно, сохранять данные пользователя plaintext`ом даже в системном хранилище это плохая идея. Это к слову об описанном мной случае излишнего доверия операционной системе. Ну и не зря же придумали Security Enclave, который позволяет хранить и шифровать данные действительно безопасно. Ведь к этому был какой-то тригер.
Да, бэкапы шифруются на пароле пользователя (если такая настройка была задана при создании бэкапа). При этом, если зашифрованная копия никогда не создавалась, пользователю необходимо задать пароль самостоятельно. А ведь, как нам известно, по статистике (по данным Avast за 2020 год) более 50% Россиян используют одинаковые пароли от разных сервисов. А во вторых, если никогда не создавалась резервная копия, то злоумышленник может самостоятельно задать свой собственный пароль и без труда получить все необходимые данные.
Да, снова вектор угрозы невелик, но защитить данные пользователя от попадания в бэкап это тоже хорошая идея.
Ну вот тут я не соглашусь. Условно, если мы ничего не храним в открытом виде ни на файловой системе, ни в KeyChain, ни где-бы то ни было еще, то особой пользы злоумышленник с Jail для себя не вынесет. А если в нашем приложении реализована проверка на наличие JailBreak, то ее еще надо обойти (да, конечно, это в большинстве случаев просто сделать, но бывают и приятные исключения). То есть тут опять путь "повышения цены" получения каких-либо данных с нашего приложения и ценность этих данных по сравнению с ценой атаки.
Отвечу на самом деле историей из жизни. Я по долгу службы часто работаю с Б/У устройствами и некоторые из них покупаю с рук. На части устройств (особенно если закупаешь массово), бывают остаются привязки к прошлым Apple ID. Такие устройства мы тоже проводим через процедуру Jailbreak, и каково было мое удивление, когда при тестировании очередного приложения и его установке, вместо стандартного welcome-экрана приложения я увидел экран с вводом пин-кода. Ну а заглянув в Keychain я нашел и тот самый пин. В результате я попал в личный кабинет человека практически не предпринимая никаких действий.
А этому есть несколько причин:
Перед продажей человек не выполнил отвязку от своего аккаунта
Приложение не осуществляло очистку KeyChain
Хранение пин-кода в открытом виде.
Да, случай редкий, мало кто так делает, но я лично столкнулся с подобным, а значит и кто-то другой может.
И в конце, если подвести итог, то конечно, возможностей по получению доступа к данным приложения в iOS существенно меньше, чем в Android, но и их нельзя сбрасывать со счетов. Какие бы средства не предоставляла операционная система, но даже с их помощью хранить в открытом виде где-бы то ни было пин-код или пароль пользователя это моветон.
Добрый день!
Спасибо большое за вопросы и комментарии! Попробую ниже свою точку зрения на это объяснить.
Можно конечно. Но на мой личный взгляд, тут стоит смотреть на процент людей, которые про эту функциональность знают, и которые ее отключают. Лично я, зная нюансы и особенности использования этого механизма оставил его включенным, потому что удобно же! Ну правда, мой внутренний безопасник спасовал перед удобством использования экосистемы.
А тех, кто вообще об этом задумывается, как мне кажется весьма мало. Это как с китайскими устройствами на подобии Xiaomi, которая передает на свои сервера просто какое-то совсем непотребное количество телеметрии с устройства и на некоторых форумах есть целый ряд способов отключит или заблокировать этот функционал. Но сколько людей об этом задумываются и сколько из них предпринимают попытки это исправить? Не думаю, что в общем масштабе это количество имеет хоть сколько значимую цифру. Так и со всеми "удобствами" от экосистемы Apple, с одной стороны удобно, с другой может быть потенциальный вектор угрозы.
В комментарии ниже отвечу.
Я про бэкап данных конкретного приложения при создании общего бэкапа устройства. Насколько я знаю, в iOS при создании зашифрованного на пароле пользователя бэкапа системы в него попадают данные приложений (KeyChain и файловая система в том числе). В случае с KeyChain, если задать правильный атрибут доступности при сохранении данных (с постфиксом ThisDeviceOnly), то в бэкап попадет значение, зашифрованное дополнительно на ключе UID и расшифровать его можно будет только на этом же самом самом устройстве и из бэкапа уже вытащить его не получится (вернее получится, но расшифровать будет проблематично).
Что касается файловой системы, то при создании файла и записи в него информаци возможно выставить атрибут, запрещающий попадание файла в локальный/облачный бэкап. Но делать это необходимо для каждого файла/директории отдельно.
Если я не прав и можно выставить некоторый "глобальный" атрибут у всего приложения, который бы запрещал бэкапы любых файлов (по аналогии с Android'овским allowBackup), я бы с удовольствием про это почитал! Возможно, я уже отстал и такой функционал появился, буду рад быть неправым :)
На самом деле аналогично пункту про синхронизацию KeyChain. Сколько людей об этом задумываются и сколько отключают.
Но и про приватность буфера обмена тоже много веселых историй на самом деле. В случае с iOS всегда было более-менее пристойно, а вот Android только с недавних версий разрешил доступ к Clipboard только приложениям, находящимся на переднем плане и активным в данный момент. До этого любое приложение могло получить доступ к буферы и считать/перезаписать в нем данные. Был случай веселого приложения, которое мониторило буфер обмена и при появлении в нем строки, попадающей под номер криптокошелька заменяло его на номер кошелька злоумышленника.
Добрый день!
В рамках прошлого года мы действительно не рассматривали iOS-приложения, а делали исследования исключительно для Android-приложений. В этом году мы обязательно исправим эту несправедливость.
Ох, это очень большой вопрос, на самом деле и очень сложный. На мой личный взгляд вся "непогрешимость" яблочных приложений основана на двух больших "китах" - это закрытая экосистема (закрытое приватное API, отсутствие исходного кода, максимальное скрытие деталей в документации и патентах) и очень сильно ограниченное взаимодействие приложений друг с другом. Это делает более сложным исследования, поиск уязвимостей и понимание того, как внутри устроена система.
С другой стороны у Apple есть уникальные вектора угроз, которые специфичны только для их экосистемы. Это и облачная синхронизация KeyChain для нескольких устройств с одним AppleId, и локальные/облачные бэкапы (если в Android разработчик может прямо запретить создавать бэкап, то в iOS подобного нет), и общий буфер обмена между устройствами и отсутствие очистки KeyChain при удалении приложения и много-много других нюансов, которые делают исследование iOS-приложений крайне увлекательным занятием.
Добрый день!
Да, не очень очевидно получилось, приношу извинения. Я имел ввиду, что поддельное приложение было для Android, а учитывая популярность официального приложения (которое изначально было только под iOS), можно представить, сколько раз установили "фальшивку" для Android.
Насколько мне известно это действительно так, в iOS нет такого же функционала, как в Android. К примеру различных экспортируемых компонентов и намного меньше возможностей для межпроцессного взаимодействия. Но вроде бы способы есть, просто я еще не дошел в своих исследованиях до этой части.
Приложения же обмениваются каким-то образом файлами для прикрепления их в почтовых клиентах или отправке через мессенджеры. Я обязательо вернусь к этой теме, когда соберу больше информации о внутреннем устройстве межпроцессного взаимодействия в iOS.
Тут играет роль и монополия несомненно и несоразмерный уровень штрафов. Но тем не менее, даже монополисты посыпали голову пеплом после произошедшего. Думаю внутри тоже немало изменений должно было произойти. Ведь это может отражаться не только на имидже компании, но и на акциях, если компания публичная (кстати интересно посмотреть, была ли какая-то корреляция цены акций и информации по утечкам).
Если будет что-то вроде GDPR, когда суммы за утечки персональных данных космические, тогда и монополистам придется об этом задуматься серьезно.