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