Как я описал в комментарии ниже, не всегда это могут быть рандомные сайты, а может и вполне себе легитимный стор.
В свое время, когда исследовали одну уязвимость в ОС Андроид, мы загружали в Google play приложение с именем пакета com.example.malware, с функционалом калькулятора и полезной нагрузкой в виде полной подмены приложения Google Photo. И ничего, никаких вопросов. Да и регулярные новости о том, что Google часто пропускает нелегитимные приложения никого уже не удивляет.
Эта статья нацелена скорее на технический обзор возможностей и разбор того, как работает данная техника атак на приложения. Ну и реакция Google, что это не баг, а фича, конечно, тоже не радует.
Касательно Apple скорее соглашусь, хотя и они не без греха. Но правила публикации сильно строже, это верно.
Все именно так, спасибо большое за пояснение. Но это не только проблема приложений, скаченных с неизвестного сайта. Это вполне может быть и легитимное приложение, загруженное из стора. В любой магазин приложений спокойно может попасть такого рода приложение и это не выявят на этапе ревью. Что уж там говорить, если даже из гугло-плея регулярно удаляют просочившуюся туда малварь и вирусы.
На самом деле все описанное это лишь технология, возможность для атаки на приложение. Уязвимость в целевом приложении и ее критичность напрямую зависят от логики работы и какой функционал выполняет открывшийся фрагмент.
Как один из примеров, это фрагмент, который принимает URL и открывает его в WebView. Конечно, так как он внутренний, никто и не думает валидировать приходящие в него параметры, его же «нельзя вызвать из вне». Дальше можно сделать, все, что пожелает фантазия. Как минимум внутри этого WebView отрисовать интерфейс в точности повторяющий интерфейс приложения и предложить пользователю ввести пин/пароль и т.д. Другой случай это работа с файлами и т.д.
С такими примерами мы сталкиваемся регулярно, с фразами «внутренний же компонент, что может случиться». Ну, а как показывает практика, случится может многое. От таких вот проблем в библиотеках, intent redirection и многого, чего мы еще пока не знаем. Это еще раз подчеркивает валидировать и проверять данные, где бы они не передавались, во внутренний ли фрагмент/активити или доступный снаружи.
Надеюсь, сто подобные проблемы научат более серьезно воспринимать слова специалистов по безопасности, хотя кого я обманываю :)
Люди запрашивают согласие там, где они НЕ ИМЕЮТ ПРАВА его запрашивать.
Не совсем понятен тезис. Согласие запрашивается для возможности обработки ПДн в случаях, для которых не допускается обработка в силу законодательства без согласия. Помимо согласия на обработку человек подтверждает и состав данных, и срок их обработки, и цели, что очень важно, и прочие обязательные сведения, в том числе о том, кто будет обрабатывать его данные и где. Нарушения закона в этом нет, наоборот.
Так вот ПДн в данном случае будут не просто фио и адрес. ВСЕ - в том числе и то, что он заказал - это ПДн.
В статье только пример набора данных, с которыми мы чаще всего сталкиваемся, не ограничивая этот список. Если при этом будет ФИО и еще какой-нибудь идентификатор человека, для исключения случаев полных тезок, то это всё ПДн в совокупности, тут полностью согласен.
Дальше по тексту возникает ощущение, что автор считает мобильное приложение обработчиком ПДн. Это в корне ошибочно.
Касательно обработчиков ПДн и мобильных приложений.
Обработчик ПДн мобильное приложение или нет - все рассуждения и выводы о сущности мобильного приложения приведены в статье. Как минимум нельзя отрицать то, что через МП проходят (равно обрабатываются) персональные данные. А архитектура приложения уже вопрос второй, но тоже немаловажный, согласен.
Вопрос о распространении законодательства о ПДн на мобильные приложения также задали в Роскомнадзор. Получим ответ - поделимся тут обязательно.
И огромное количество дыр в приложениях популярных производителей лишний раз это доказывает. И это только проблемы с безопасностью, а что каждый вендор накрутил с точки зрения системных приложений и модификации ОС это очень большой вопрос, особенно на no-name устройствах.
ОС первична и, к сожалению, может быть модифицирована, поэтому и надо иметь это ввиду при разработке приложений.
Проверялись приложения Android при помощи инструмента, который мы разрабатываем, а именно «Стингрей».
Анализ приложений из публичных источников (различные маркетплейсы приложений), при помощи статического анализа (по декомпилированным исходникам), динамического анализа (запуск приложения и анализ его работы + активные проверки) и еще несколькими другими практиками, который поддерживает наш инструмент.
Отчет действительно предполагает некоторую форму для заполнения, все таки мы компания, нам бы хотелось знать, кто загрузил отчет и кому было бы интересно получать информацию о наших исследованиях и статьях.
И мы действительно принимаем данные любые, так как если не хочешь, чтобы узнали, ну значит, так надо :)
Если интересно, могу предоставить отчет в личных сообщениях.
А за наводку про политику по обработке, спасибо большое, я посмотрю, почему так вышло.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 100К мы не доберем, но проверить эту историю реально.
Как я описал в комментарии ниже, не всегда это могут быть рандомные сайты, а может и вполне себе легитимный стор.
В свое время, когда исследовали одну уязвимость в ОС Андроид, мы загружали в Google play приложение с именем пакета com.example.malware, с функционалом калькулятора и полезной нагрузкой в виде полной подмены приложения Google Photo. И ничего, никаких вопросов. Да и регулярные новости о том, что Google часто пропускает нелегитимные приложения никого уже не удивляет.
Эта статья нацелена скорее на технический обзор возможностей и разбор того, как работает данная техника атак на приложения. Ну и реакция Google, что это не баг, а фича, конечно, тоже не радует.
Касательно Apple скорее соглашусь, хотя и они не без греха. Но правила публикации сильно строже, это верно.
Все именно так, спасибо большое за пояснение. Но это не только проблема приложений, скаченных с неизвестного сайта. Это вполне может быть и легитимное приложение, загруженное из стора. В любой магазин приложений спокойно может попасть такого рода приложение и это не выявят на этапе ревью. Что уж там говорить, если даже из гугло-плея регулярно удаляют просочившуюся туда малварь и вирусы.
На самом деле все описанное это лишь технология, возможность для атаки на приложение. Уязвимость в целевом приложении и ее критичность напрямую зависят от логики работы и какой функционал выполняет открывшийся фрагмент.
Как один из примеров, это фрагмент, который принимает URL и открывает его в WebView. Конечно, так как он внутренний, никто и не думает валидировать приходящие в него параметры, его же «нельзя вызвать из вне». Дальше можно сделать, все, что пожелает фантазия. Как минимум внутри этого WebView отрисовать интерфейс в точности повторяющий интерфейс приложения и предложить пользователю ввести пин/пароль и т.д. Другой случай это работа с файлами и т.д.
С такими примерами мы сталкиваемся регулярно, с фразами «внутренний же компонент, что может случиться». Ну, а как показывает практика, случится может многое. От таких вот проблем в библиотеках, intent redirection и многого, чего мы еще пока не знаем. Это еще раз подчеркивает валидировать и проверять данные, где бы они не передавались, во внутренний ли фрагмент/активити или доступный снаружи.
Надеюсь, сто подобные проблемы научат более серьезно воспринимать слова специалистов по безопасности, хотя кого я обманываю :)
Не могу не согласиться :)
Полностью согласен, но это отдельная боль на самом деле.
И пока что я еще не настолько глубоко в это погрузился, чтобы об этом можно было писать. Возможно чуть позже доберусь до этого и распишу!
Спасибо огромное за дополнение!
Не совсем понятен тезис. Согласие запрашивается для возможности обработки ПДн в случаях, для которых не допускается обработка в силу законодательства без согласия. Помимо согласия на обработку человек подтверждает и состав данных, и срок их обработки, и цели, что очень важно, и прочие обязательные сведения, в том числе о том, кто будет обрабатывать его данные и где. Нарушения закона в этом нет, наоборот.
В статье только пример набора данных, с которыми мы чаще всего сталкиваемся, не ограничивая этот список. Если при этом будет ФИО и еще какой-нибудь идентификатор человека, для исключения случаев полных тезок, то это всё ПДн в совокупности, тут полностью согласен.
Касательно обработчиков ПДн и мобильных приложений.
Обработчик ПДн мобильное приложение или нет - все рассуждения и выводы о сущности мобильного приложения приведены в статье. Как минимум нельзя отрицать то, что через МП проходят (равно обрабатываются) персональные данные. А архитектура приложения уже вопрос второй, но тоже немаловажный, согласен.
Вопрос о распространении законодательства о ПДн на мобильные приложения также задали в Роскомнадзор. Получим ответ - поделимся тут обязательно.
Если бы мы знали, что это такое, но мы не знаем, что это такое)))Но, думаю, это слишком просто.
Ну а если более серьезно, к сожалению, виды обработки не ограничиваются только сбором.
Ох, это очень непросто..
Особенно, учитывая все требования, которые предъявляются к сертифицированному ПО и сам процесс сертификации.
Поделитесь опытом пожалуйста, в итоге получилось сделать мобильное приложение, сертифицированное ФСТЭК?
Все именно так!
И огромное количество дыр в приложениях популярных производителей лишний раз это доказывает. И это только проблемы с безопасностью, а что каждый вендор накрутил с точки зрения системных приложений и модификации ОС это очень большой вопрос, особенно на no-name устройствах.
ОС первична и, к сожалению, может быть модифицирована, поэтому и надо иметь это ввиду при разработке приложений.
Нет, при анализе не учитывали, что пользователь может что-то не разрешить.
Как показывает практика, почти всегда разрешают все :)
Пусть допущение, но правдивое)
А это к чему?)
Не очень понял отсылки, к сожалению)
Проверялись приложения Android при помощи инструмента, который мы разрабатываем, а именно «Стингрей».
Анализ приложений из публичных источников (различные маркетплейсы приложений), при помощи статического анализа (по декомпилированным исходникам), динамического анализа (запуск приложения и анализ его работы + активные проверки) и еще несколькими другими практиками, который поддерживает наш инструмент.
Отчет действительно предполагает некоторую форму для заполнения, все таки мы компания, нам бы хотелось знать, кто загрузил отчет и кому было бы интересно получать информацию о наших исследованиях и статьях.
И мы действительно принимаем данные любые, так как если не хочешь, чтобы узнали, ну значит, так надо :)
Если интересно, могу предоставить отчет в личных сообщениях.
А за наводку про политику по обработке, спасибо большое, я посмотрю, почему так вышло.
Полностью согласен, поэтому и написал эту статью, так как мне показалось, что данная атака была недостаточно раскрыта и недооценена.
Или комьюнити или инструмент, который по SBOM позволит сказать, какие проблемные компоненты есть в приложении.
Как минимум для мобильных приложений мы уже выпустили подобный функционал. Думаю, что и для Java появится в скором времени что-то подобное.
Думаю что поправят. Скорее всего добавили на скорую руку для быстроты.
Но да, информация предоставлена не лучшим образом, сходу не разберешься.
Полностью согласен.
Но на мой взгляд, техническое решение есть. Для начала проверить, что в проекте нет зависимостей со свободными доменами, избавиться от них (если нашли) и в дальнейшем проверять подключаемые библиотеки. Причем, как на эту атаку, так и просто на уязвимости.
Благо технические средства для этого уже есть. Как минимум для мобильных приложений мы уже выпустили подобный функционал.
молодцы они, быстро сориентировались :)
Мы тоже сегодня выпустили релиз, который позволяет идентифицировать библиотеки, подверженные этой атаке. Правда, мы разделили на два типа проблем, библиотеки со свободными доменами и с доменами, которые были куплены после выхода информации об атаке.
И это для мобильных приложений.
Спасибо большое за дополнение и за команду! Да, действительно, получается, что сгенерировать этот файл относительно легко.
Но мне кажется, что тут основная работа - это убедиться, что там уже нет скомпрометированных библиотек и следить за этим файлом во время обновления библиотек (если они не меняются, то наверное и вполне резонно его использовать).
Спасибо!
Добрый день!
Атака похожа, но все-таки отличается, в той атаке был смысл во внутренних библиотеках, которые разрабатывались и хранились внутри компании и не были доступны публично. И если первым стоял публичный репозиторий, то он пытался скачать их оттуда.
Но безусловно сходство есть, влияние расположения репозиториев в файле сборки.
Интересная мысль, спасибо!
Я думаю для следующего обновления приложения мы как раз используем схему со всеми этапами тестирования и посмотрим, насколько изменится ситуация в этом случае.
Так-то, конечно, до 100К мы не доберем, но проверить эту историю реально.
Спасибо!