Android permission get tasks

Недопустимое разрешение GET_TASKS

У меня есть приложение безопасности (App Locker), которое использует это разрешение:

В android Lollipop это разрешение устарело, и я хочу, чтобы мое приложение работало в API +21.
Может ли кто-нибудь вести меня как?

Есть причина, почему это устарело. Уровень защиты android.permission.GET_TASKS повышен до signatureOrSystem. Для этого нет простого и безотлагательного решения.

Начиная с LOLLIPOP, этот метод больше не доступен для сторонних приложений: введение ссылочных ссылок означает, что он может передавать личную информацию вызывающему. Для обратной совместимости он по-прежнему будет возвращать небольшое подмножество своих данных: по крайней мере, собственные задачи вызывающего абонента (хотя см. GetAppTasks () для правильного поддерживаемого способа получения этой информации) и, возможно, некоторые другие задачи, такие как дома, которые известны Не чувствительны.

Я видел новое разрешение REAL_GET_TASKS, которое, как говорят, используется вместо GET_TASKS:

Новая версия GET_TASKS, которую могут запрашивать приложения, поскольку GET_TASKS не предоставляет доступ к информации о задачах. Нам нужен этот новый, потому что есть много существующих приложений, которые используют библиотеки добавок и такие, которые имеют код проверки, чтобы убедиться, что приложение запросило разрешение GET_TASKS, увидев, было ли ему предоставлено разрешение … если оно этого не произошло, оно убивает Приложение с сообщением о том, что он расстроен. Поэтому нам нужно, чтобы он продолжал выглядеть так, как будто приложение получает это разрешение, даже если оно никогда не будет проверено, и новые привилегированные приложения теперь могут запросить это для реального доступа.

Источник

Страшная сказка на ночь для пользователей Android

Каждый, наверное, сталкивался с сайтами, предлагающими пользователю платную подписку на ту или иную услугу. В силу специфики моей работы мне иногда приходится проверять подобные ресурсы. Чаще всего они наспех набиты контентом, фальшивыми комментариями и созданы специально для обмана пользователя. Создатели обещают золотые горы, а на деле все заканчивается банальным разводом на деньги. Данная статья — один из частных случаев анализа фейк-сайта с приложением для Android.

Все началось с того, что мне прислали на проверку сайт. По виду — обычный варезный блог с громкими заголовками типа “Бесплатные обои и картинки для андроида”, “Самые умные программы на андроид” и тому подобное. Сразу бросилось в глаза, что во всех постах одинаковые комментарии, оставленные “разными людьми”. Содержание примерно следующее:

— Сайт просит ввести номер телефона, это нормально?
— Да, это для регистрации, проверка, что ты не бот.
— О, круто, спасибо!

В общем факт обмана виден сразу, но я решил копать дальше. При попытке загрузить приложение из любого поста с помощью стационарного компьютера, меня перекидывает на другой ресурс. Ссылка вида http://****/**/?sub_id=* (ага, возможно партнерочка). Там мне предлагают купить за деньги Google Chrome (и ведь ведутся же люди!).

Допустим… Но ведь ресурс посвящен приложениям для Android устройств, значит, нужно попробовать зайти с девайса. Как и следовало ожидать: вместо предложения купить супер-браузер загружается install.apk. “Вот это уже интересно” — подумал я и не ошибся.

Первое, что бросилось в глаза — огромное количество потенциально опасных разрешений.

Не слабый набор, правда? Мне стало интересно, что же приложение делает со всеми этими разрешениями.

Не буду описывать сам процесс декомпиляции, лишь упомяну, что использовал apktools, dex2jar, JD-GUI и jad. В итоге я получил декомпилированные ресурсы и набор классов.

Читайте также:  Кот том игрушка андроид

Первое, на что я обратил внимание, это, разумеется, AndroidManifest.xml.

Коротко о разрешениях:

READ_PHONE_STATE — получение информации о телефоне (номер телефона, серийник, информация о вызовах);
SEND_SMS — отправка sms-сообщений;
RECEIVE_SMS — прием sms-сообщений и последующее удаление их (именно поэтому приоритет у MainReceiver наивысший);
INTERNET — использование интернета;
WAKE_LOCK — отключает спящий режим (видимо для повышения стабильности :);
ACCESS_NETWORK_STATE — информация о сетевых соединениях;
RECEIVE_BOOT_COMPLETED — получать сообщения о загрузке устройства, что позволяет выполнять приложение при запуске;
WRITE_EXTERNAL_STORAGE — запись/удаление информации на карте памяти;
INSTALL_PACKAGES — приложение может устанавливать или обновлять пакеты;
DELETE_PACKAGES — приложение может удалять пакеты;
READ_CONTACTS — доступ к контактам;
CALL_PHONE — осуществляет телефонные вызовы;
CALL_PRIVILEGED — осуществляет телефонные вызовы, в том числе по экстренным номерам;
GET_TASKS — получение данных о запущенных приложениях;
SYSTEM_ALERT_WINDOW — показывает сообщения поверх всех окон;
RESTART_PACKAGES — способно завершать фоновые процессы других приложений (официальное описание);
KILL_BACKGROUND_PROCESSES — способно завершать фоновые процессы других приложений (официальное описание);
READ_LOGS — чтение конфиденциальных данных из журнала.

Так же есть ресивер, который срабатывает на следующие намерения:

SMS_RECEIVED — получено sms-сообщение;
custom.alarm — внутреннее событие;
BOOT_COMPLETED — загрузка завершена;
USER_PRESENT — пользователь разблокировал устройство;
PHONE_STATE — изменение состояния сотовой сети (не знаю, как выразиться корректней, также позволяет мониторить вызовы пользователя);
SCREEN_OFF — при отключении экрана;
SCREEN_ON — при включении экрана.

Так как времени на изучение приложение у меня было немного (стояла задача в общих чертах узнать, что делает приложение), я не стал вдаваться во все тонкости. Почти все URL там зашифрованы, и для расшифровки нужно просидеть не один час. Можно, конечно, получить их с помощью WireShark, но в этом нет необходимости.

Работа приложения

Пришло время заглянуть в декомпилированные классы. Начнем пожалуй с MainActivity. Я прокомментирую функции, на которые стоит обратить внимание:

При детальном анализе можно увидеть, что сообщение отправляется сразу, а не после нажатии кнопки “Далее” (как это обычно принято). Лицензионное соглашение есть, но оно очень хорошо запрятано. Но отправка сообщения — это не самая страшная проблема. Помните большое количество разрешений? Давайте посмотрим, зачем они все-таки нужны приложению.

Чтобы сэкономить место и ваше время, я не буду выкладывать MainReceiver. Сразу скажу, что он обрабатывает и удаляет (!) входящие сообщения, а в случае необходимости еще и отвечает.

Самое интересное находится в MainService. При запуске сервис подключается к серверу, запрашивает оттуда данные, получает нечто в json и при успешном ответе запускает метод executeCommands(jsonobject1). И тут начинается магия:

Фактически это троянский конь. Классический такой троянский конь, позволяющий сливать данные пользователя и управлять его телефоном.

Резюме

На хабре не тот контингент, которому стоит читать нотацию на тему “не ставьте не проверенные приложения”, поэтому данную часть своего выступления я опущу.

Первые вредоносные приложения просто отправляли платные sms-сообщения, потом начали рассылать себя всем из списка контактов, а теперь — мы имеем полноценную троянскую лошадь, которую можно дергать за поводья удаленно. Эволюция…

Перечислю еще раз вкратце (для тех, кто пролистал, не читая код с моими комментариями) что умеет делать приложение:

1. Менять URL основного сервера
2. Устанавливать sms-фильтры (удалять то, что попадает в фильтр еще до того, как пользователь успеет получить уведомление)
3. Удалять сообщения
4. Отправлять сообщения
5. Выполнять http-запросы (botnet. )
6. Проверять наличие обновлений и обновляться
7. Удалять произвольные пакеты
8. Отправлять пользователю нотификации
9. Открывать произвольный URL
10. Сливать контакты на сервер
11. Сливать список установленных приложений на сервер
12. Выполнять произвольные вызовы (например, в Замбези)
13. Использовать Twitter в качестве альтернативного способа обновления некоторых данных (к сожалению, декомпиляция прошла с ошибками и не все файлы удалось просмотреть).

Читайте также:  Стили кнопок для андроид студио

Источник

Разрешения Android 6.0 в защите и нападении

Содержание статьи

Каждый день в мобильных устройствах выявляют уязвимости, которые могут быть проэксплуатированы злоумышленниками. Они могут отправить СМС на платный номер, могут собрать большую базу данных контактов и продать ее, а могут и скомпрометировать конкретного человека. Удачная эксплуатация уязвимости обычно предполагает соблюдение целого ряда условий. Но ведь можно пойти и другим путем! Дать пользователю вполне нужное приложение (игрушку с птичками), у которого в манифесте будет записан список интересной нам информации на устройстве. В данной статье мы рассмотрим способы получения и сохранения важной информации с Android-устройства.

Архитектура ОС Android построена таким образом, что позволяет обмениваться разного рода информацией между приложениями. Приложению, работающему с картами, нужно местоположение, диктофону — доступ к микрофону. Таким образом, с виду все ясно и прозрачно.

Мы открыто прописываем в манифесте приложения требуемые данные или возможности и получаем их при установке. Никто никого не обманывает, все добровольно. Но проблема состоит в том, что пользователи ужасно неграмотны в информационных технологиях. Мало кто задумывается, для чего тому же диктофону требуется твое местоположение или доступ к СМС. Приложение открыто заявляет о своих намерениях в манифесте, и странно было бы ожидать от него другого поведения.

Задолго до всем известного разоблачения я понимал, что игрушка со злыми птичками на твоем устройстве — это стукач, так как оно, помимо всего прочего, хочет читать идентификатор устройства и данные о вызовах. Простой вопрос «Тебе эти данные зачем?» обнажает истинные намерения ее создателей.

Пользователь при установке приложения ставится в положение «или разрешай все, что оно хочет, или останешься без программы». Только единицы пойдут в магазине искать приложение со сходной функциональностью, но с меньшими запросами (аналогов может вовсе не быть), поэтому у пользователей быстро входит в привычку жать «да-да-да» на все вопросы. Согласись, легко привыкать, когда за долгие годы офлайн-жизни у пользователей вырабатывался рефлекс автоматически подписывать многостраничные договоры, по принципу «ну, все же подписывают, наверное, тут ничего плохого, да и выход всего один — либо я подписываю тут, либо не получаю того, за чем пришел».

Если мы отберем все разрешения у приложения, ОС во избежание падения программы может просто отдать ему пустые значения. Можно обмануть приложение, подсунув ему заведомо ложные данные (местоположение Северного полюса) или просто нули. Например, приложение может спросить список контактов на устройстве, и разработчик предполагает в своей архитектуре, что он может быть пустым (совсем новое устройство). Тут даже и заподозрить нечего — и данные спасены, и приложение не сломалось.

На такие ухищрения приходилось идти вплоть до версии Android 6.0 Marshmallow. В ней появился новый механизм работы с разрешениями.

Он позволяет давать и забирать разрешения во время работы самого приложения. Для обратной совместимости старых аппликух (то есть у которых значение targetSdkVersion меньше 23) работает старый механизм запроса разрешений при установке. Обновленные приложения должны запрашивать разрешения в процессе работы. В настройках приложения мы можем посмотреть, к чему у приложения есть доступ, и при желании отозвать этот самый акцесс.

Рассмотрим работу данного механизма на устройстве с версией Android 6.0.

Давай установим птичек, но перед первым запуском отберем у них все права. При запросе прав при установке из гуглплея мы видим, что targetSdkVersion у приложения меньше 23. Экран настроек говорит нам о несколько завышенных интересах создателей приложения.

Читайте также:  Андроид как посмотреть удаленные вызовы
Запрос прав при установке птичек из маркета

Хакер #204. Шифровальщик для Android

Как насчет того, чтобы немного их укоротить?

Забираем разрешения Вот так-то будет лучше

После отзыва разрешений я запустил игру, и оказалось, что нормальной работе это ничуть не помешало. Видимо, фоновый сервис сбора данных никак не влияет на основной игровой интерфейс.

Теперь давай рассмотрим работу с обновленным приложением Skype. Вот перед нами часть манифеста «похожего» приложения. Список разрешений и требований из манифеста приложения вдохновляет:

Если бы только пользователи это видели.

Раз мы хотим сохранить хотя бы малую долю частной жизни, остается уповать только на операционную систему. Рассмотрим процесс установки приложения. При установке из маркета никаких диалоговых окон не показывается — все разрешения приложение будет спрашивать потом. Проверим в настройках.

У скайпа разрешений нет У скайпа разрешений совсем нет

Запустим приложение. Последовательно идут семь запросов.

Запрос скайпа 1

Последовательно отклоняем все запросы, и скайп превращается в интернет-чат :).

Постой, я сказал «в интернет-чат»? А почему он не спросил разрешения на доступ в интернет? А все потому, что разрешения делятся на две группы: обычные и опасные. Доступ теперь должны запрашивать только последние. Список обычных разрешений можно посмотреть тут. А вот — опасные разрешения (и их группы). Для создания запросов на разрешения есть подробные материалы: шаблоны использования запросов на доступ к разрешениям, рекомендации для доступа к разрешениям, а вот и полный список разрешений.

С теорией мы более-менее разобрались, теперь перейдем к практике.

Проникаем в список контактов (по-хорошему)

Обогащенные этим новым знанием, давай напишем небольшое приложение, в котором будем читать данные о контактах пользователя через запросы в интерфейсе и в сервисе. Как недавно выяснилось, некоторые приложения очень часто любят читать эти данные (оно и неудивительно — вдруг там что-то изменилось, а создатели «хороших» приложений и не знают).

Нажатием на кнопку мы проверяем версию ОС и, если она 23 и выше, делаем запрос на получение прав:

Диалог на запрос прав

После диалога в методе onRequestPermissionsResult нужно обработать ответ:

Читаем контакты в одну строчку с переходами на новую строку:

Показываем контакты в окне, при клике по окну оно скроется:

А вот результат работы чтения контактов:

Забыл взять контакты у совы

Проникаем в список контактов (по-плохому)

Теперь проделаем то же самое, но в сервисе, как и положено плохому приложению. Сервис никаких запросов слать не будет, а будет пытаться просто в лоб читать контакты.

Запуск сервиса сделаем по событию подключения к Wi-Fi .
Код сервиса:

Если у приложения есть права, то сервис покажет Toast сообщение со списком контактов, если прав нет — вызовет ошибку с сообщением. Теперь исследуем поведение приложения, если выставить ему targetSdkVersion ниже 23.

По умолчанию приложению были выданы права, и все работает штатно без запросов. После отключения прав в настройках приложения список контактов стал приходить пустым. Никаких ошибок мы не получили, но и контактов тоже. Значит, без нашего ведома приложения будут получать неактуальную информацию.

Заключение

Новая версия Android включает в себя более надежные и гибкие настройки прав для приложений. Можно сказать, что в новой версии наши данные защищены более эффективно, но это не значит, что теперь тебе можно вслепую соглашаться со всеми предложениями, поступающими из всплывающих окошек. Будь бдителен!

Источник

Оцените статью