Uses permission android name android permission read contacts

Описание

Элемент является корневым элементом манифеста. По умолчанию Eclipse создает элемент с четырьмя атрибутами:

Атрибуты

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

android:name название разрешения android:label имя разрешения, отображаемое пользователю android:description описание разрешения android:icon значок разрешения android:permissionGroup определяет принадлежность к группе разрешений android:protectionLevel уровень защиты

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

android:name имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе

данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений, например: android:name=»android.permission.CAMERA» или android:name=»»android.permission.READ_CONTACTS»

Наиболее распространенные разрешения

• INTERNET — доступ к интернету
• READ_CONTACTS — чтение (но не запись) данных из адресной книги пользователя
• WRITE_CONTACTS — запись (но не чтение) данных из адресной книги пользователя
• RECEIVE_SMS — обработка входящих SMS
• ACCESS_COARSE_LOCATION — использование приблизительного определения местонахождения при помощи вышек сотовой связи или точек доступа Wi-Fi
• ACCESS_FINE_LOCATION — точное определение местонахождения при помощи GPS

объявляет базовое имя для дерева разрешений. Этот элемент объявляет не само разрешение, а только пространство имен, в которое могут быть помещены дальнейшие разрешения.

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

разрешения, так и объявленные в другом месте. Этот элемент не объявляет разрешение непосредственно, только категорию, в которую могут быть помещены разрешения. Разрешение можно поместить в группу, назначив имя группы в атрибуте permissionGroup элемента

Источник

Страшная сказка на ночь для пользователей 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-приложениях

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

Как известно, безопасность обеспечивается системой разрешений доступа на каждом конкретном Android-устройстве. Эта система призвана защищать важные данные и предотвращать несанкционированный доступ к информации или каналам связи.

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

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

Здесь мы рассмотрим существующую систему манифестов и разрешений в Android. Файл манифеста содержит информацию о пакете приложения, включая разрешения, поставщиков контента, сервисы, активности и широковещательных приёмников (broadcast receivers).

Пример общей структуры файла манифеста. Цветом выделены запросы на получение разрешений:

Самые опасные разрешения

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

Разрешения, которые в будущем вы возможно захотите пересмотреть

Запрос root-прав. Пользователь с root-правами может управлять системой без каких-либо ограничений. По умолчанию в Android таких прав не даётся, поскольку неопытные пользователи могут натворить бед. Root-права предоставляются процессом под названием “Rooting the Android device”. И если их получает злонамеренное приложение, то оно сможет делать всё, что ему заблагорассудится.

Вот небольшой пример того, как приложение запускает shell-скрипт с правами привилегированного пользователя, чтобы перезагрузить устройство:

С помощью команды su приложение запускается с привилегированными правами, и если устройство рутованно, то оно перезагружается. Если же нет, то появляется сообщение:

Чтобы запросить доступ к root:

нужно добавить в файл манифеста строку:

Запрос разрешения на чтение и запись личных данных. Если вы хотите, чтобы пользователи не переживали за свои личные данные, то не используйте в манифесте подобные запросы:

Разрешения, связанные с финансовыми расходами. Некоторые разрешения, бездумно предоставленные пользователями, могут стоить им денег. Чаще всего это отправка SMS/MMS и совершение голосовых вызовов. Причём происходить это может в фоновом режиме, без вызова стандартного телефонного приложения.
Запрос на отправку сообщений:

Запрос на совершение звонков:

Простой пример отправки SMS:

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

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

• примерном местоположении пользователя согласно данным базовых станций и точек Wi-Fi;
• точном местоположении пользователя согласно данным GPS, базовых станций и Wi-Fi.

Запрос доступа к данным о примерном местоположении:

Запрос доступа к данным о точном местоположении:

Вот как осуществляется получение данных о точном местоположении:

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

Java-класс MainActivity внедряет LocationListener для получения нужных данных от устройства. Запрос текущего местоположения осуществляется вызовом requestLocationUpdates() в методе onCreate() . Когда местоположение изменяется, то для получения новых данных вызывается onLocationChanged() . Если GPS-данные недоступны, то вызывается метод onProviderDisabled(), передающий приложению информацию о местоположении.

Доступ к аудио- и видео. Если пользователь даёт такие разрешения, то он рискует тем, что его будут прослушивать или использовать камеру смартфона для слежки. Запросы доступа в файле манифеста:

Установка пакетов. Если дать такое разрешение, то приложение сможет устанавливать дополнительные пакеты без ведома пользователя.

Остановка фоновых процессов. Данное разрешение позволяет приложению вызывать killBackgroundProcesses(String), с чьей помощью оно может останавливать любые выполняющиеся в фоновом режиме процессы.

Источник