Комментарии 20
Каким образом можно получить доступ к песочнице с помощью локальных или облачных бекапов? Нехорошее приложение может попросить чтения внешней папки?
Добрый день!
Локальный бэкап имеется ввиду снятие резервной копии приложении при подключении к компьютеру или функционал резервного копирования в облачные сервисы.
При возможности сделать локальный бэкап в Android приложениях внутрь него попадают файлы из песочницы приложения. После, можно разархивировать полученный файл бэкапа, посмотреть или даже модифицировать какие-то значения и восстановить из резервной копии. Мы как-то так развлекались, обходя локальный счетчик на проверку пин-кода. Два раза пробуешь код, восстанавливаешься из бэкапа, где этот счетчик равен нулю и продолжаешь дальше до победного. Конечно, есть способы намного проще, но это было интересно.
В случае с iOS, когда создается резервная копия устройства, в нее также попадают и файлы приложения. А если копия защищена паролем, то и элементы сумки ключей (KeyChain) также оказываются внутри и имея доступ к этой копии, можно получить эти данные.
Что касается облачной копии - тут немного сложнее, но также возможно. Как минимум для iOS существуют инструменты для извлечения данных из облачных сервисов iCloud. А еще есть шаринг элементов KeyChain между устройствами на одной учетной записи Apple и много еще интересных возможностей.
Для этого в большинстве нужен физический доступ к устройству, но это один из векторов для мобильных устройств.
Лучше бы кто-то написал обратный крик души про мифы безопасности андроид приложений:
Зачем этой апе доступ к моим звонкам? Она будет слушать мои звонки?
Зачем этой апе автозапуск?
Апа яндекса читает мои телеграм-уведомления!
И так далее.
Может быть в следующий раз напишу и об этом.
На самом деле, в большинстве случаев перебор с правами в Android-приложениях часто обусловлен или библиотеками, которым что-то нужно для корректной работы или ужасной системой permissions в Android. Например, для того, чтобы корректно работал Bluetooth на некоторых версиях системы нужно было запрашивать доступ к геопозиции (и другие подобные примеры).
Google, конечно работает над разделением, но не сильно быстро пока что это получается. Коллеги отмечали это, когда разбирали что нового в Android, может интересно будет послушать.
А так да, конечно, фонарики с доступом к смс и звонкам это прям классика :)
Четвёртый пункт миф до поры до времени, пока компания не станет монополией, о чём собственно в самой статье и говорится. Нет конкурентов - нет проблем с репутацией.
Так что прежде, чем списывать со счетов репутационные риски, подумайте,
сколько клиентов удалят ваше мобильное приложение или уйдут к
конкурентам после того, как произойдет подобный инцидент и выйдет статья
с подробным описанием уязвимости.
Собственно это легко наблюдается и в современном мире на примере провалов сбера и яндекса в сливах персональных данных пользователей. Сливы произошли, репутация понизилась, но приложения продолжают работать, клиенты продолжают пользоваться приложениями. Как раз это и говорит о том, что репутация ничего не стоит, с учётом успешно выстроенной монополии. А такие монополии в современном мире не редкость.
Тут играет роль и монополия несомненно и несоразмерный уровень штрафов. Но тем не менее, даже монополисты посыпали голову пеплом после произошедшего. Думаю внутри тоже немало изменений должно было произойти. Ведь это может отражаться не только на имидже компании, но и на акциях, если компания публичная (кстати интересно посмотреть, была ли какая-то корреляция цены акций и информации по утечкам).
Если будет что-то вроде GDPR, когда суммы за утечки персональных данных космические, тогда и монополистам придется об этом задуматься серьезно.
Не стыковка в предложении:
Например, поддельное приложение Club House для Android выполняло ........... Учитывая, что официальное iOS-приложение скачали свыше 13 миллионов раз ......
Все-таки Android или iOS?
В iOS приложения не могут залезать в другие приложения за данными, на сколько я знаю.
Добрый день!
Не стыковка в предложении:
Да, не очень очевидно получилось, приношу извинения. Я имел ввиду, что поддельное приложение было для Android, а учитывая популярность официального приложения (которое изначально было только под iOS), можно представить, сколько раз установили "фальшивку" для Android.
В iOS приложения не могут залезать в другие приложения за данными, на сколько я знаю.
Насколько мне известно это действительно так, в iOS нет такого же функционала, как в Android. К примеру различных экспортируемых компонентов и намного меньше возможностей для межпроцессного взаимодействия. Но вроде бы способы есть, просто я еще не дошел в своих исследованиях до этой части.
Приложения же обмениваются каким-то образом файлами для прикрепления их в почтовых клиентах или отправке через мессенджеры. Я обязательо вернусь к этой теме, когда соберу больше информации о внутреннем устройстве межпроцессного взаимодействия в iOS.
Посмотрел ваше исследование, явно не увидел, но, похоже, что оно только для Android-приложений.
iOS - все хорошо или вы просто не исследовали яблочную безопасность?
Про Android и так известно, что много рисков использования, начиная с самой системы. А вот подобное исследование по Apple было бы очень интересным, а то есть у некоторых вера в непогрешимость яблок. На сколько она обоснована?
Добрый день!
Посмотрел ваше исследование, явно не увидел, но, похоже, что оно только для Android-приложений.
iOS - все хорошо или вы просто не исследовали яблочную безопасность?
В рамках прошлого года мы действительно не рассматривали iOS-приложения, а делали исследования исключительно для Android-приложений. В этом году мы обязательно исправим эту несправедливость.
А вот подобное исследование по Apple было бы очень интересным, а то есть у некоторых вера в непогрешимость яблок. На сколько она обоснована?
Ох, это очень большой вопрос, на самом деле и очень сложный. На мой личный взгляд вся "непогрешимость" яблочных приложений основана на двух больших "китах" - это закрытая экосистема (закрытое приватное API, отсутствие исходного кода, максимальное скрытие деталей в документации и патентах) и очень сильно ограниченное взаимодействие приложений друг с другом. Это делает более сложным исследования, поиск уязвимостей и понимание того, как внутри устроена система.
С другой стороны у Apple есть уникальные вектора угроз, которые специфичны только для их экосистемы. Это и облачная синхронизация KeyChain для нескольких устройств с одним AppleId, и локальные/облачные бэкапы (если в Android разработчик может прямо запретить создавать бэкап, то в iOS подобного нет), и общий буфер обмена между устройствами и отсутствие очистки KeyChain при удалении приложения и много-много других нюансов, которые делают исследование iOS-приложений крайне увлекательным занятием.
Это и облачная синхронизация KeyChain для нескольких устройств с одним AppleId,
Можно отключить, и иметь локальные независимые копии.
и локальные/облачные бэкапы
Шифрование. Я об этом ниже написал.
(если в Android разработчик может прямо запретить создавать бэкап, то в iOS подобного нет)
Есть.
Хотя, возможно, я тут не так понял. Вы про бэкап всей системы, или данных конкретного приложения при создании бэкапа?
и общий буфер обмена между устройствами
Легко включается/отключается в настройках.
Добрый день!
Спасибо большое за вопросы и комментарии! Попробую ниже свою точку зрения на это объяснить.
Можно отключить, и иметь локальные независимые копии.
Можно конечно. Но на мой личный взгляд, тут стоит смотреть на процент людей, которые про эту функциональность знают, и которые ее отключают. Лично я, зная нюансы и особенности использования этого механизма оставил его включенным, потому что удобно же! Ну правда, мой внутренний безопасник спасовал перед удобством использования экосистемы.
А тех, кто вообще об этом задумывается, как мне кажется весьма мало. Это как с китайскими устройствами на подобии Xiaomi, которая передает на свои сервера просто какое-то совсем непотребное количество телеметрии с устройства и на некоторых форумах есть целый ряд способов отключит или заблокировать этот функционал. Но сколько людей об этом задумываются и сколько из них предпринимают попытки это исправить? Не думаю, что в общем масштабе это количество имеет хоть сколько значимую цифру. Так и со всеми "удобствами" от экосистемы Apple, с одной стороны удобно, с другой может быть потенциальный вектор угрозы.
Шифрование. Я об этом ниже написал.
В комментарии ниже отвечу.
Есть.
Хотя, возможно, я тут не так понял. Вы про бэкап всей системы, или данных конкретного приложения при создании бэкапа?
Я про бэкап данных конкретного приложения при создании общего бэкапа устройства. Насколько я знаю, в iOS при создании зашифрованного на пароле пользователя бэкапа системы в него попадают данные приложений (KeyChain и файловая система в том числе). В случае с KeyChain, если задать правильный атрибут доступности при сохранении данных (с постфиксом ThisDeviceOnly), то в бэкап попадет значение, зашифрованное дополнительно на ключе UID и расшифровать его можно будет только на этом же самом самом устройстве и из бэкапа уже вытащить его не получится (вернее получится, но расшифровать будет проблематично).
Что касается файловой системы, то при создании файла и записи в него информаци возможно выставить атрибут, запрещающий попадание файла в локальный/облачный бэкап. Но делать это необходимо для каждого файла/директории отдельно.
Если я не прав и можно выставить некоторый "глобальный" атрибут у всего приложения, который бы запрещал бэкапы любых файлов (по аналогии с Android'овским allowBackup), я бы с удовольствием про это почитал! Возможно, я уже отстал и такой функционал появился, буду рад быть неправым :)
Легко включается/отключается в настройках.
На самом деле аналогично пункту про синхронизацию KeyChain. Сколько людей об этом задумываются и сколько отключают.
Но и про приватность буфера обмена тоже много веселых историй на самом деле. В случае с iOS всегда было более-менее пристойно, а вот Android только с недавних версий разрешил доступ к Clipboard только приложениям, находящимся на переднем плане и активным в данный момент. До этого любое приложение могло получить доступ к буферы и считать/перезаписать в нем данные. Был случай веселого приложения, которое мониторило буфер обмена и при появлении в нем строки, попадающей под номер криптокошелька заменяло его на номер кошелька злоумышленника.
Но на мой личный взгляд, тут стоит смотреть на процент людей, которые про эту функциональность знают, и которые ее отключают. Лично я, зная нюансы и особенности использования этого механизма оставил его включенным, потому что удобно же!
А мне не удобно, и я сразу отключил. Знаю людей кто тоже отключал.
Но сколько людей об этом задумываются и сколько из них предпринимают попытки это исправить?
Вы знаете, по личному опыту — их не так уж и мало.
Не думаю, что в общем масштабе это количество имеет хоть сколько значимую цифру. Так и со всеми "удобствами" от экосистемы Apple, с одной стороны удобно, с другой может быть потенциальный вектор угрозы.
Как говорил один мой знакомый — самый безопасный компьютер — отключенный от сети питания и помещенный в сейф.
Я про бэкап данных конкретного приложения при создании общего бэкапа устройства.
А вот тут все несколько интересно :)
Все разы когда я пытался сделать полный бэкап андроид аппарата (разных производителей), данные приложений не попадали в него. Только системные настройки, звонки и т.п.
А мне как-бы очень хотелось, чтобы у меня был полный бэкап системы, чтобы в случае чего просто взять и восстановить полностью работоспособный телефон за 20 минут. Про безопасность бэкапа я могу сам позаботиться.
Насколько я знаю, в iOS при создании зашифрованного на пароле пользователя бэкапа системы
При шифровании локального бэкапа ставится отдельный пароль.
Бэкап в icloud шифруется, емнип, с привязкой к apple id.
Как оно работает внутри я не могу сказать, разработкой под ios не занимаюсь.
На самом деле аналогично пункту про синхронизацию KeyChain. Сколько людей об этом задумываются и сколько отключают.
Как минимум изучают настройки и гуглят/спрашивают довольно многие.
Как говорил один мой знакомый — самый безопасный компьютер — отключенный от сети питания и помещенный в сейф.
Именно так! А самый безопасный код - который не работает! :)
Все разы когда я пытался сделать полный бэкап андроид аппарата (разных производителей), данные приложений не попадали в него.
А, я немного не понял вопроса просто. Да, в Android возможно сделать бэкап конкретного приложения со всеми его файлами, если разработчик это не запретил (а может и вообще переопределил в коде поведение при бэкапе). При бэкапе устройства - это системные штуки.
В iOS же, вроде бы, нельзя сделать бэкап конкретного приложения, но при полном бэкапе устройства в него попадают файлы приложений, а если он зашифрован, то и данные KeyChain.
В ios, емнип, можно сделать бэкап одного приложения через третьесторонние тулзы (но там авторизация доступа, все дела, т.е. не просто так взять и вытащить). Но вообще, сходу погуглил, и вроде как тоже можно исключить какие-то файлы/каталоги из бэкапа.
то и данные KeyChain.
Насколько я понимаю — нет. Keychain это отдельная сущность со своими файлами.
Но вот для iOS он лишь сохраняет передаваемые в него данные в открытом виде в KeyChain. То есть, если вы захотите сохранить пароль или пинкод пользователя (что уже само по себе не очень хорошо) и используете этот плагин в приложении для iOS, то на выходе вы получите сохраненный в открытом виде в KeyChain пароль от аккаунта пользователя.
Подождите, но ведь содержимое keychain шифруется? И дешифруется (и то, не все сразу) только при некоторых условиях.
Несмотря на то, что это хранилище считается защищенным, крайне не рекомендуется содержать в нем данные в открытом виде, так как они могут быть получены через локальный или облачный бэкап, при физическом доступе к устройству или при наличии Jailbreak.
Бэкапы же тоже шифруются?
А при наличии Jailbreak, в принципе, можно забыть про бОльшую часть защиты. Аналог — получение рута на андроиде через патчер от Васяна с 4pda.
А в некоторых случаях их можно добыть и при продаже устройства, если разработчик не имплементировал очистку KeyChain после переустановки продукта.
Но как? Keychain привязан к apple id.
И снова спасибо! :)
Перед ответом на конкретные вопросы отвечу - да, действительно многие вещи шифруются. И 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, но и их нельзя сбрасывать со счетов. Какие бы средства не предоставляла операционная система, но даже с их помощью хранить в открытом виде где-бы то ни было пин-код или пароль пользователя это моветон.
есть и инструменты, которые позволяют подобрать пароли и от учетных записей iCLoud и от локальных бэкапов
А можно плз подробнее? Про "взлом" icloud я читал только в контексте соц.инжиниринга/фишинга/итп.
Подбор пароля локального бэкапа? Ну удачи :)
способов получения данных из KeyChain несколько
Насколько помню, доступ даже к локальному средствами OS завязан на залогиненом юзере. Можно вытащить сам файл, но все интересное в нем зашифровано.
Да, бэкапы шифруются на пароле пользователя
На локальные бэкапы можно ставить отдельный пароль.
Ну вот тут я не соглашусь. Условно, если мы ничего не храним в открытом виде ни на файловой системе, ни в KeyChain, ни где-бы то ни было еще, то особой пользы злоумышленник с Jail для себя не вынесет.
Можно же тупо подменить прикладной/системный софт, который легально взаимодействует с шифрованным хранилищем.
Я по долгу службы часто работаю с Б/У устройствами и некоторые из них покупаю с рук.
На старых устройствах и версиях ОС можно встретить много дичи :)
когда при тестировании очередного приложения и его установке, вместо стандартного welcome-экрана приложения я увидел экран с вводом пин-кода. Ну а заглянув в Keychain я нашел и тот самый пин.
Это вопросы исключительно к кривизне рук разраба этого приложения.
Какие бы средства не предоставляла операционная система, но даже с их помощью хранить в открытом виде где-бы то ни было пин-код или пароль пользователя это моветон.
Так пароли в открытом доступе то нигде и не лежат. Вообще, вопросы безопасности — они на совести пользователя. Если отключить 2FA и поставить пароль вида "123", то можно не удивляться последствиям :)
А можно плз подробнее? Про "взлом" icloud я читал только в контексте соц.инжиниринга/фишинга/итп.
Подбор пароля локального бэкапа? Ну удачи :)
Компания ElcomSoft как раз занимается разработкой инструментов для форензики, в том числе инструментами для подбора пароля от локальных/облачных бэкапов (с применением GPU и прочих радостей). Ну и вытаскивание данных из iCloud.
Ну и другие продукты для форензики мобильных телефонов тоже так умеют, просто я работал только с ElcomSoft.
Насколько помню, доступ даже к локальному средствами OS завязан на залогиненом юзере. Можно вытащить сам файл, но все интересное в нем зашифровано.
А нам сам файл не нужен, мы от имени приложения "легально" можем обратиться к хранилищу. Я выше описывал примеры, как это можно сделать, используя туже самую Frida. Да, это требует JailBreak, но это вполне возможно.
На локальные бэкапы можно ставить отдельный пароль.
Я это и имел ввиду, да. Пароль пользователя не от устройства, а тот, что он задает при создании бэкапа, возможно не так выразился.
Можно же тупо подменить прикладной/системный софт, который легально взаимодействует с шифрованным хранилищем.
Ну вот для Security Enclave пока ничего подобного не придумали. Это отдельный сопроцессор для выполнения различных операций, связанных с безопасностью и шифрованием данных. Весьма занятная штука, но я редко встречаю его использование в приложениях.
На старых устройствах и версиях ОС можно встретить много дичи :)
Это точно)) Но в основном на данный момент это iOS 14 и постепенно переходим на 15
Это вопросы исключительно к кривизне рук разраба этого приложения.
Абсолютно согласен. Но ведь и поведение системы весьма странное, удаляем файлы, но оставляем данные в KeyChain...
Так пароли в открытом доступе то нигде и не лежат. Вообще, вопросы безопасности — они на совести пользователя. Если отключить 2FA и поставить пароль вида "123", то можно не удивляться последствиям :)
Ну не в открытом доступе, да) Но в открытом виде (plaintext), тоже так себе. Конечно, пользователь сам себе злой буратино, но в интересах разработчика (или безопасника) попробовать сделать приложение более безопасным. Ну или хотя бы усложнить путь для выстрела себе в ногу.
в том числе инструментами для подбора пароля от локальных/облачных бэкапов (с применением GPU и прочих радостей)
Как-то очень сомнительно. В брутфорс пароля локального бэкапа еще можно поверить (в принципе никакого рокет сайенс тут нет), то в подбор пароля для icloud уже с трудом (там же 2FA, количество попыток, и т.п.).
Да, это требует JailBreak, но это вполне возможно.
Вот я про это и писал. С jailbreak пользователь сильно урезает безопасность своего аппарата.
Но в основном на данный момент это iOS 14 и постепенно переходим на 15
В 16 добавили advanced data protection и возможность отключить доступ к icloud через веб. Плюс на новых аппаратах все грустно с уязвимостями/jailbreak.
Но ведь и поведение системы весьма странное, удаляем файлы, но оставляем данные в KeyChain
Емнип, для обновления/удаления записи нужно делать запрос пользователю. Возможно при удалении приложения средствами системы тут все несколько сложно.
Но в открытом виде (plaintext), тоже так себе.
Ну так у разработчика есть все необходимое чтобы безопасно хранить чувствительные данные.
Шорт-лист мифов о безопасности мобильных приложений и неприкрытая правда