И огромное количество дыр в приложениях популярных производителей лишний раз это доказывает. И это только проблемы с безопасностью, а что каждый вендор накрутил с точки зрения системных приложений и модификации ОС это очень большой вопрос, особенно на no-name устройствах.
ОС первична и, к сожалению, может быть модифицирована, поэтому и надо иметь это ввиду при разработке приложений.
Проверялись приложения Android при помощи инструмента, который мы разрабатываем, а именно «Стингрей».
Анализ приложений из публичных источников (различные маркетплейсы приложений), при помощи статического анализа (по декомпилированным исходникам), динамического анализа (запуск приложения и анализ его работы + активные проверки) и еще несколькими другими практиками, который поддерживает наш инструмент.
Отчет действительно предполагает некоторую форму для заполнения, все таки мы компания, нам бы хотелось знать, кто загрузил отчет и кому было бы интересно получать информацию о наших исследованиях и статьях.
И мы действительно принимаем данные любые, так как если не хочешь, чтобы узнали, ну значит, так надо :)
Если интересно, могу предоставить отчет в личных сообщениях.
А за наводку про политику по обработке, спасибо большое, я посмотрю, почему так вышло.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 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.
Ох, это очень непросто..
Особенно, учитывая все требования, которые предъявляются к сертифицированному ПО и сам процесс сертификации.
Поделитесь опытом пожалуйста, в итоге получилось сделать мобильное приложение, сертифицированное ФСТЭК?
Все именно так!
И огромное количество дыр в приложениях популярных производителей лишний раз это доказывает. И это только проблемы с безопасностью, а что каждый вендор накрутил с точки зрения системных приложений и модификации ОС это очень большой вопрос, особенно на no-name устройствах.
ОС первична и, к сожалению, может быть модифицирована, поэтому и надо иметь это ввиду при разработке приложений.
Нет, при анализе не учитывали, что пользователь может что-то не разрешить.
Как показывает практика, почти всегда разрешают все :)
Пусть допущение, но правдивое)
А это к чему?)
Не очень понял отсылки, к сожалению)
Проверялись приложения Android при помощи инструмента, который мы разрабатываем, а именно «Стингрей».
Анализ приложений из публичных источников (различные маркетплейсы приложений), при помощи статического анализа (по декомпилированным исходникам), динамического анализа (запуск приложения и анализ его работы + активные проверки) и еще несколькими другими практиками, который поддерживает наш инструмент.
Отчет действительно предполагает некоторую форму для заполнения, все таки мы компания, нам бы хотелось знать, кто загрузил отчет и кому было бы интересно получать информацию о наших исследованиях и статьях.
И мы действительно принимаем данные любые, так как если не хочешь, чтобы узнали, ну значит, так надо :)
Если интересно, могу предоставить отчет в личных сообщениях.
А за наводку про политику по обработке, спасибо большое, я посмотрю, почему так вышло.
Полностью согласен, поэтому и написал эту статью, так как мне показалось, что данная атака была недостаточно раскрыта и недооценена.
Или комьюнити или инструмент, который по SBOM позволит сказать, какие проблемные компоненты есть в приложении.
Как минимум для мобильных приложений мы уже выпустили подобный функционал. Думаю, что и для Java появится в скором времени что-то подобное.
Думаю что поправят. Скорее всего добавили на скорую руку для быстроты.
Но да, информация предоставлена не лучшим образом, сходу не разберешься.
Полностью согласен.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
молодцы они, быстро сориентировались :)
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
И это для мобильных приложений.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Спасибо!
Добрый день!
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Интересная мысль, спасибо!
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 100К мы не доберем, но проверить эту историю реально.
Спасибо!
Уверен, что так оно и есть на самом деле.
Просто странно, что это в таком случае не указано в их политике. Было бы написано, вопросов бы вообще не было.
Я и сам считаю, что это не задача магазинов - в обязательном порядке проверять все приложения на уязвимости, это весьма трудоемко и сложно, учитывая и объемы и разнообразие технологий даже в мобилках. Но если уж ты об этом заявляешь - делай это хорошо =)
Здравствуйте!
Да, есть такие планы, но пока что приложение в разработке. Да и немного труднее там получить сертификат разработчика и пройти формальные процедуры. Но мы справимся.
Здравствуйте!
К сожалению, не большой в этом эксперт, но на самом деле такие проверки вполне могут иметь неплохой шанс обнаружить что-то нехорошее на устройстве. Как минимум по известным сигнатурам проанализировать apk-файлы, которые установлены очень даже возможно. Они как раз лежат в директории, к которой есть доступ у всех приложений, поэтому спокойно можно их посмотреть и сравнить (некоторый аналог VirusTotal).
Более продвинутые приложения такого рода умеют анализировать намного больше вещей, которые косвенно могут означать наличие проблем. Так что я бы не преуменьшал их значимости, проверяют что-то и хорошо, какой-то вектор закрывают. Но и рассчитывать только на них, конечно же не стоит.
Здравствуйте!
Хорошая идея, попробуем чуть попозже в гугл и остальные магазины направить репорт о том, сколько всего мы в своем приложении нашли, действительно интересно, как они отреагируют, может даже небольшое продолжение напишем.
Здравствуйте!
Согласен, в Android, особенно в версиях с 11-го, весьма неплохо Google постарался. Но речь все-таки больше про ошибки, которые допускаются на уровне приложений, которые некоторые магазины обещают проверять. Тут, сколько приложения не зажимай в правах, а такие проблемы все равно будут.
И я как раз хотел показать, что нельзя надеяться на такого рода проверки и что за безопасностью надо в первую очередь следить самим.
Компания ElcomSoft как раз занимается разработкой инструментов для форензики, в том числе инструментами для подбора пароля от локальных/облачных бэкапов (с применением GPU и прочих радостей). Ну и вытаскивание данных из iCloud.
Ну и другие продукты для форензики мобильных телефонов тоже так умеют, просто я работал только с ElcomSoft.
А нам сам файл не нужен, мы от имени приложения "легально" можем обратиться к хранилищу. Я выше описывал примеры, как это можно сделать, используя туже самую Frida. Да, это требует JailBreak, но это вполне возможно.
Я это и имел ввиду, да. Пароль пользователя не от устройства, а тот, что он задает при создании бэкапа, возможно не так выразился.
Ну вот для Security Enclave пока ничего подобного не придумали. Это отдельный сопроцессор для выполнения различных операций, связанных с безопасностью и шифрованием данных. Весьма занятная штука, но я редко встречаю его использование в приложениях.
Это точно)) Но в основном на данный момент это iOS 14 и постепенно переходим на 15
Абсолютно согласен. Но ведь и поведение системы весьма странное, удаляем файлы, но оставляем данные в KeyChain...
Ну не в открытом доступе, да) Но в открытом виде (plaintext), тоже так себе. Конечно, пользователь сам себе злой буратино, но в интересах разработчика (или безопасника) попробовать сделать приложение более безопасным. Ну или хотя бы усложнить путь для выстрела себе в ногу.
Именно так! А самый безопасный код - который не работает! :)
А, я немного не понял вопроса просто. Да, в Android возможно сделать бэкап конкретного приложения со всеми его файлами, если разработчик это не запретил (а может и вообще переопределил в коде поведение при бэкапе). При бэкапе устройства - это системные штуки.
В iOS же, вроде бы, нельзя сделать бэкап конкретного приложения, но при полном бэкапе устройства в него попадают файлы приложений, а если он зашифрован, то и данные KeyChain.