Андроид безопасность – Безопасность Мобильного бесплатно — скачать Безопасность Мобильного для Андроид бесплатно

Разбираемся в системе обеспечения безопасности Android — «Хакер»

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

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

 

Введение

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

В пример обычно приводились приложения, использующие эксплойты ядра Linux, которые позволяли получить права root, а затем сделать с системой все, что захочет злоумышленник. Этих нескольких найденных уязвимостей хватило, чтобы создать в желтой прессе шумиху, которая не улеглась и по сей день.

Но как же обстоят дела на самом деле? Проблема существует или нет? Стоит ли бояться юзерам Android за сохранность своих данных, или перейти на iOS, и как, если это возможно, защитить свои данные от злоумышленников? Обо всем этом повествует наш сегодняшний обзор.

Архитектура Android

 

Дыра в дыре?

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

Реализуется это простым и превосходным методом: через соблюдение прав доступа. В Android каждое приложение — это отдельный пользователь со своими правами доступа и полномочиями. Каждое приложение в такой системе получает свой собственный идентификатор пользователя (UID) и собственный каталог внутри каталога /data, так что все его данные защищаются с помощью простых прав доступа, которые разрешают самому приложению читать собственные файлы, но запрещают делать это любому другому процессу.

Увидеть, какому UID принадлежит приложение, можно с помощью любого менеджера задач

В Android это называется песочницей (sandboxing), которая позволяет сберечь данные соседних приложений друг от друга, не позволив зловреду утащить частную информацию, сохраненную любым приложением системы. В песочницу попадают абсолютно все приложения, включая заранее предустановленные на аппарат. Фактически лишь небольшая часть Android работает с правами root, а именно начальный процесс zygote, выполняющий функции контроля за исполнением приложений, и небольшая часть системных сервисов. Все остальные приложения всегда работают в песочницах, поэтому зловред, даже прошедший процедуру «впаривания» пользователю, не может утащить ничего ценного, кроме содержимого SD-карты, доступ к которой по умолчанию открыт всем (позже мы еще вернемся к этому).

Кроме данных отдельно взятых приложений, для доступа закрыта также базовая инсталляция Android, размещаемая на отдельном разделе внутренней NAND-памяти и подключенная к каталогу /system. По умолчанию она смонтирована в режиме только для чтения и, в принципе, не хранит в себе никакой конфиденциальной информации (для ее размещения также используются песочницы в /data), поэтому каким-то хитрым образом прописаться в автозагрузку или модифицировать системные компоненты не получится (если, конечно, не использовать эксплойты для получения прав root, о чем я подробнее расскажу ниже).

Для общения приложениям доступно несколько вариантов IPC, причем родные для Linux средства коммуникации, такие как разделяемая память и сокеты, доступны только процессам, принадлежащим одному приложению, да и то лишь в том случае, если хотя бы часть приложения написана на компилируемом в машинный код языке, то есть с использованием Android NDK. Во всех остальных случаях приложения смогут использовать Binder для безопасного обмена сообщениями и интенты для вызова сторонних приложений (о них мы также поговорим ниже).

Ознакомиться со списком полномочий приложения можно и после его установки

Интересно, что в Android, начиная с версии 2.2, есть понятие администратора устройства, но значит оно совсем не то, что под ним понимают пользователи UNIX и Windows. Это просто API, с помощью которого приложение может изменять политику безопасности паролей, а также запрашивать необходимость в шифровании хранилища данных и производить удаленный вайп смартфона. Это своего рода костыль, который был придуман в ответ на запросы корпоративных пользователей Android, которые хотели получить больший контроль над безопасностью данных на смартфонах сотрудников. Фактически этим API может воспользоваться любое приложение, но для этого пользователь должен явно подтвердить свое намерение предоставить приложению такие полномочия. Также в последних версиях Android появилась возможность загрузки устройства в безопасном режиме, когда пользователь получает доступ только к предустановленным приложениям. Она может понадобиться в случае компрометации устройства сторонним приложением.

Начиная с версии 3.0, Android имеет встроенную поддержку шифрования всех пользовательских данных с помощью стандартной подсистемы dmcrypt ядра Linux. Шифрование производится в отношении того самого каталога /data алгоритмом AES128 в режиме CBC и ESSIV:SHA256 с помощью ключа, генерируемого на основе пароля, который необходимо ввести во время загрузки ОС. При этом стоит учитывать, что карта памяти не шифруется, поэтому сохраненные на ней данные остаются полностью открытыми.

 

Приложения и права доступа

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

У Android есть замечательная особенность: абсолютно любое приложение обязано содержать в себе информацию о том, какие именно из функций Android оно может использовать. Эта информация заключена в файле AndroidManifest.xml внутри APK-файла и извлекается инсталлятором перед установкой приложения для того, чтобы пользователь смог ознакомиться с тем, к какой функциональности смартфона приложение сможет получить доступ. При этом пользователь должен в обязательном порядке согласиться с этим списком перед установкой приложения.

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

Также хочется заметить, что все возможные привилегии достаточно четко и логично разделены, благодаря чему злоупотребления привилегиями практически не бывает. Например, приложение может потребовать возможность читать SMS, но не отправлять их или получать уведомления о пришедшем сообщении. Фактически единственный серьезный недостаток системы привилегий был найден только в том, что инженеры Google вообще не предусмотрели никаких ограничений на чтение карты памяти (запись тем не менее ограничена), посчитав это бессмысленным для съемных накопителей. В свое время эта «брешь» привела к возможности получения координат смартфона, выуженных из кеша стандартного приложения «Галерея», который хранился на карте памяти. Что, в свою очередь, вынудило Google добавить в настройки последних версий Android опцию, после активации которой система будет явно спрашивать пользователя о возможности доступа какого-либо приложения к SD-карте.

Еще одна важная особенность такой системы заключается в том, что пользовательские настройки всегда будут приоритетнее запросов приложений, а это значит, что, если пользователь отключит GPS, приложение никак не сможет включить его самостоятельно даже при наличии всех прав на использование GPS. При этом некоторые функции ОС недоступны для приложений вовсе. Например, манипулировать SIM-картой имеет право только операционная система, и никто, кроме нее.

Проверка привилегий идет на самом низком уровне ОС, в том числе на уровне ядра Linux, так что для обхода этой системы безопасности зловреду придется не только получить права root на устройстве, но и каким-то образом скомпрометировать ядро, что гораздо более сложная задача.

 

IPC

Как уже было сказано выше, приложения могут обмениваться информацией, используя стандартные для Android средства коммуникации Binder, интенты (Intents) и провайдеры данных (Content Provider). Первый представляет собой механизм удаленного вызова процедур (RPC), реализованный на уровне ядра Linux, но контролируемый системным сервисом Service Manager. С точки зрения программного интерфейса Binder является всего лишь средством импорта объектов из другого приложения, но с точки зрения безопасности полностью контролируется обсуждаемым выше механизмом разграничения прав доступа. Это значит, что приложения смогут получить доступ друг к другу только в том случае, если оба этого захотят. Это особенно важно в свете того, что в Android Binder является основным средством коммуникации, на основе которого построен графический интерфейс, а также другие компоненты ОС, доступные программисту. Доступ к ним ограничивается с помощью обсуждаемого выше механизма привилегий. Как системные компоненты, так и сторонние приложения могут ограничивать доступ к своей функциональности с помощью декларации прав на доступ к своим функциям. В случае системных компонентов все они описаны в документации для программистов Android-приложений. Независимые разработчики, которые хотят открыть API к своим приложениям, должны описать требуемые для этого привилегии в AndroidManifest.xml и опубликовать соответствующую документацию. Все это относится также к провайдерам данных (Content Provider), специальному интерфейсу (также реализованному поверх Binder), с помощью которого приложения могут открывать доступ к своим данным другим приложениям. В Android провайдеры данных везде, это и адресная книга, и плей-листы, и хранилище настроек. Доступ к ним опять же ограничивается с помощью механизма привилегий и прав доступа.

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

Принцип работы Binder

Сами по себе перечисленные механизмы обмена данными и вызова функций приложений, контролируемые с помощью системы привилегий, в Android реализованы достаточно четко и ясно, однако они могут привести к проблемам в том случае, если программист недостаточно серьезно относится к декларации привилегий, необходимых для доступа к своему приложению. Это может привести к утечкам информации или возможности задействования функциональности приложения кем угодно. Например, в первых версиях Dropbox для Android имелась проблема с правильным определением привилегий, которая приводила к тому, что любое установленное приложение могло использовать Dropbox-клиент для заливки какой угодно информации на «облачный диск» www.securelist.com.

 

Защита от срыва стека

Для защиты приложений, созданных с использованием Android NDK, а также системных компонентов, написанных на языке Си, Android включает в себя обширный набор механизмов защиты от срыва стека, в свое время реализованных самыми разными разработчиками для различных проектов. В Android 1.5 системные компоненты были переведены на использование библиотеки safe-iop, реализующей функции безопасного выполнения арифметических операций над целыми числами (защита от integer overflow). Из OpenBSD была позаимствована реализация функции dmalloc, позволяющая предотвратить атаки с использованием двойного освобождения памяти и атаки согласованности чанков, а также функция calloc с проверкой на возможность целочисленного переполнения во время операции выделения памяти. Весь низкоуровневый код Android, начиная с версии 1.5, собирается с задействованием механизма компилятора GCC ProPolice для защиты от срыва стека на этапе компиляции.

В версии 2.3 в коде были устранены все возможные уязвимости манипуляции со строками, выявленные с помощью сборки исходных текстов с флагами ‘-Wformat-security’, ‘-Werror=format-security’, а также применены «железные» механизмы защиты от срыва стека (бит No eXecute (NX), доступный начиная с ARMv6). Также Android 2.3 задействует метод защиты от уязвимости, найденной в ноябре 2009 года во всех ядрах Linux 2.6 (возможность разыменования NULL-указателя), с помощью записи отличного от нуля значения в файл /proc/sys/vm/mmap_min_addr. Такой метод защиты позволил устранить уязвимость без необходимости в обновлении самого ядра Linux, что невозможно на многих устройствах.

Начиная с версии 4.0, Google внедрила в Android технологию Address space layout randomization (ASLR), которая позволяет расположить в адресном пространстве процесса образ исполняемого файла, подгружаемых библиотек, кучи и стека случайным образом. Благодаря этому эксплуатация многих типов атак существенно усложняется, поскольку атакующему приходится угадывать адреса перехода для успешного выполнения атаки. В дополнение, начиная с версии 4.1, Android собирается с использованием механизма RELRO (Read-only relocations), который позволяет защитить системные компоненты от атак, основанных на перезаписи секций загруженного в память ELF-файла. В той же версии 4.1 была впервые активирована функция ядра dmesg_restrict (/proc/sys/kernel/dmesg_restrict), появившаяся в ядре 2.6.37 и позволяющая отключить возможность чтения системного журнала ядра (dmesg) непривилегированными пользователями.

 

INFO

-В альтернативной Android-прошивке MIUI ни одно стороннее приложение не сможет отправить SMS без явного подтверждения со стороны пользователя.

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

• В рамках экспериментального проекта SE Android идет работа над форком Android с активированной системой безопасности SELinux.

 

Репозиторий приложений

Репозиторий приложений Google Play (в девичестве Android Market) всегда был самым слабым местом Android. Несмотря на то что механизм, требующий от приложений обязательного указания списка своих привилегий перед установкой, изначально работал правильно и позволял создать экосистему, в которой пользователи сами бы могли предупреждать друг друга о возможном зловредном поведении программы, опубликованной в репозитории, пользователи то и дело заражали свои смартфоны вирусами.

Основная проблема здесь заключалась в том, что приложение и его автор не подвергались каким-либо серьезным проверкам перед публикацией пакета в репозиторий. Фактически все, что нужно было сделать, — это написать программу, создать аккаунт в Google Play, внести членский взнос и опубликовать приложение. Все это мог сделать абсолютно любой человек, выложив в Маркет любой код, что и было многократно продемонстрировано в различных исследованиях безопасности Android.

Чтобы хотя бы частично решить эту проблему, не прибегая к ручной проверке приложений на безопасность, как сделано в Apple App Store, Google в начале этого года ввела в строй сервис Bouncer, представляющий собой виртуальную машину, в которой автоматически запускается любое публикуемое в репозитории приложение. Bouncer выполняет многократный запуск софтины, производит множество действий, симулирующих работу пользователя с приложением, и анализирует состояние системы до и после запуска с целью выяснить, не было ли попыток доступа к конфиденциальной информации, отправки SMS на короткие платные номера и так далее.

По словам Google, Bouncer позволил сократить количество вредоносов сразу после запуска сервиса на 40%. Однако, как показали дальнейшие исследования, его можно было легко обойти: проанализировать некоторые характеристики системы (e-mail-адрес владельца «смартфона», версию ОС и так далее) и затем создать приложение, которое при их обнаружении не будет вызывать подозрений, а после попадания на настоящий смартфон делать всю грязную работу.

Скорее всего, Google уже разработала схему противодействия обнаружению Bouncer с помощью генерации уникальных виртуальных окружений для каждого нового приложения, но так или иначе вирусы будут продолжать проникать в Google Play, и стоит быть внимательным при установке приложений, обязательно читая отзывы пользователей и анализируя список полномочий приложения перед его установкой.

 

Ревью кода и обновления

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

В Google на постоянной основе работает команда безопасности Android (Android Security Team), задача которой заключается в том, чтобы следить за качеством кода операционной системы, выявлять и исправлять найденные в ходе разработки новой версии ОС ошибки, реагировать на отчеты об ошибках, присланные пользователями и секьюрити-компаниями. В целом эта команда работает в трех направлениях:

• Анализ новых серьезных нововведений ОС на безопасность. Любое архитектурное изменение Android должно быть в обязательном порядке одобрено этими ребятами.
• Тестирование разрабатываемого кода, в котором принимают участие также Google Information Security Engineering team и независимые консультанты. Идет постоянно на протяжении всего цикла подготовки нового релиза ОС.
• Реагирование на обнаружение уязвимости в уже выпущенной ОС. Включает в себя постоянный мониторинг возможных источников информации о найденной уязвимости, а также поддержку стандартного баг-трекера.

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

1. Уведомляет компании, входящие в альянс OHA (Open Handset Alliance), и начинает обсуждение возможных вариантов решения проблемы.
2. Как только решение будет найдено, в код вносятся исправления.
3. Патч, содержащий решение проблемы, направляется членам OHA.
4. Патч вносится в репозиторий Android Open Source Project.
5. Производители/операторы начинают обновление своих устройств в режиме OTA или публикуют исправленную версию прошивки на своих сайтах.

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

Приложениям вход в каталог с частной информацией других приложений закрыт

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

В выводе ps хорошо видно, что все приложения с правами разных пользователей

 

Выводы

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

 

Безопасность Android: взгляд внутрь

Несомненно Android сегодня является самой распространённой в мире мобильной системой. Грамотный маркетинг, широкий ассортимент, гибкое ценообразование и поддержка платформы со стороны внушительного числа ИТ-гигантов и производителей стали одними из главных факторов успеха этой ОС и позволили системе занять лидирующее положение на рынке. Но, как и любая другая система, Android, к сожалению, не может быть полностью безопасной, так как разработчики никогда не смогут создать идеальный код. А популярность платформы привлекает все больше злоумышленников готовых использовать уязвимости системы в корнистых целях.

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

Предпосылки к появлению угроз Android

1. Открытость

Открытость системы Android заключается в нескольких факторах. Во-первых, это доступность кода, который может быть использован, модифицирован и улучшен разработчиками в зависимости от их потребностей и идей. С одной стороны, для производителей устройств и разработчиков это несомненный плюс, с другой стороны, это дает возможность не только исследователям, но и злоумышленникам более продуктивно находить уязвимости и ошибки. Во-вторых, существует возможность установить приложения как из официального каталога приложений Google Play (ранее назывался Android Market), так и из любого другого доступного источника. В-третьих, создание приложений является практически общедоступным, так как необходимо заплатить всего $25 в случае, если разработчик желает размещать свои продукты в официальном каталоге, а для распространения программ вне его материальные затраты вообще не нужны. В-четвертых, размещаемые в Google Play программы до недавнего времени не подвергались предварительной проверке или тестированию со стороны Google. Совсем недавно была анонсирована система Bouncer , которая должна проверять приложения, размещенные в каталоге Play, на наличие вредоносных функций; проверке также будут подвергаться учетные записи разработчиков.

2. Фрагментация платформы

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

3. Человеческий фактор: халатность, социальная инженерия и глупость

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

Приложения также могут подделываться, и невнимательный пользователь с большой долей вероятности поделится со злоумышленниками своими персональными данными (логин и пароль от социальной сети, данные кредитной карты и т. п.). Вариантов может быть много.

Теория механизмов безопасности Android

Система Android базируется на ядре Linux, тем не менее ее разработчики сильно модифицировали некоторые базовые механизмы, что в конечном итоге привело и к усилению защиты. В частности, рабочая среда Android включает в себя драйверы оборудования, поддержку сетевого стека, файловую систему, а также механизмы управления памятью, процессорным временем и расходом электроэнергии. Все эти механизмы реализуются с помощью библиотек, написанных на языке Си/Си++, но все приложения для Android исполняются в виртуальной машине Dalvik VM, которая, по своей сути, является подмножеством Java 5 Standard Edition.

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

Каждое приложение Android имеет собственный идентификатор и запускается в собственной виртуальной машине. Для каждой такой машины действует принцип изоляции по потокам и низкоуровневому распределению памяти. Все взаимодействие отдельных процессов происходит только через ядро Linux, а не напрямую. В Android вместо одного пользователя с высокими привилегиями предусмотрено целых три: root, system и rild. ОС Android во время загрузки в память запускает мастер-процесс zygote, который порождает новые экземпляры Dalvik VM — по одному для каждого приложения. Кроме того, во время старта ОС запускается несколько системных процессов system_server, которые реализуют все необходимые сервисы операционной системы: процесс init, инициализирующий операционную систему; mountd, отвечающий за работу со съемными дисками; rild, управляющий взаимодействием с телефонной сетью и другими коммуникационными интерфейсами.

В Android используется отличный от принятого в Linux механизм распределения прав, называемый привилегиями. Так, есть привилегии для работы с мобильной сетью (например, CALL_PHONE), работы с изображениями (CAMERA) или доступа к Интернет (INTERNET), и, чтобы получить определенные привилегии, приложение должно их декларировать в своем описании. При установке приложения набор этих привилегий проверяется, и пользователю предлагается их подтвердить. Например, первый отечественный троянец, который рассылал SMS на платные короткие номера, при установке просил привилегии на отсылку SMS. А поскольку он представлялся как медиаплеер, то подобное разрешение должно было насторожить пользователя — зачем плееру нужны права на отсылку SMS?

Все эти механизмы позволяют решить основную проблему Linux — всесилие пользователя root. Поскольку каждое приложение запускается под своим идентификатором, то и запущенные процессы можно легко классифицировать по приложениям и определить для каждого из них правила контроля доступа к объектам ОС. При этом для доступа к радиосети нужно получить доступ не столько к идентификатору root, сколько к пользователю rild, который обеспечивает работу сетевых сервисов. Фактически в Android используется классическая модель разделения властей в государстве: root выполняет законодательные функции, занимаясь конфигурацией, rild — исполнительные функции, связанные сетью, а system — судебную, контролируя работу внутрисистемных сервисов.

Основные угрозы и атаки на Android

1. Вирусы и другое вредоносное ПО

Итак, какие вредоносные программы для ОС Android существуют и чем они опасны?

Список уверенно возглавляют СМС-троянцы (семейство Android.SmsSend). Целью таких программ является отправка сообщений с повышенной тарификацией на короткие номера. Часть стоимости этих сообщений поступает в карман злоумышленников, обогащая их.  Чаще всего они распространяются под видом популярных приложений и игр, таких как Opera Mini, ICQ, Skype, Angry Birds и т. п., при этом используется соответствующая иконка.

Далее по списку следуют более «тяжеловесные» троянцы. К ним относятся, например, Android.Gongfu, Android.Wukong, Android.DreamExploid, Android.Geinimi, Android.Spy и пр. В зависимости от семейства, эти вредоносные программы обладают таким функционалом, как, например, сбор конфиденциальной информации пользователя, добавление закладок в браузер, выполнение команд, поступающих от злоумышленников (функции бэкдора и бота), отправка СМС-сообщений, установка других приложений и т. п.

Однако, нужно понимать, что бы реализовать возможность установки приложений, не вызывая подозрений со стороны пользователя, троянцам необходимы права root (права, с которыми работает ядро системы).

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

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

2. Уязвимости Android и ПО

Архитектура Android построена таким образом, что все приложения работают с ограниченными правами и не имеют доступа к защищенным данным других приложений. Начиная с Android 5.0 в системе по умолчанию включен режим SELinux (Security Enhanced Linux). Он предусматривает принудительный контроль прав доступа на уровне ядра ОС.

Одна из главных проблем, с которыми могут столкнуться пользователи, — уязвимости системы, позволяющие получить права root. Существуют специальные приложения, скрипты и программные модули, выполняющие эту задачу. В повседневной жизни подобные вещи пользователям не страшны, так как чаще всего их используют осознанно для получения большего контроля над устройством. Другое дело, что эти же уязвимости (например, CVE-2009-1185 , CVE-2011-1823 ) взяли на вооружение создатели вредоносных приложений. Используя эксплойты (те самые программные модули и скрипты) для повышения своих прав до уровня root, они получают возможность, например, беспрепятственно устанавливать другие программы без разрешения пользователя (как это делают различные модификации Android.Gongfu и Android.DreamExploid). Некоторые вредоносные программы не используют эксплойты сами, напрямую, а вводят пользователя в заблуждение и побуждают его самого выполнить необходимые действия, тем самым дав вредоносной программе требуемые ей возможности.

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

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

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

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

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

А теперь более подробно о методах защиты платформы Android

Безопасность физического доступа

1.1 Экран блокировки. Чтобы никто не считал личную информацию пока наш смартфон находится вне поля зрения, нужно обязательно ставить защиту на разблокировку экрана. Это можно сделать разными способами:

• Пароль – классический надежный способ, если конечно пароль сложный. Единственная неудобность состоит в том, что не совсем здорово десятки раз за день вводить такой пароль.
• Графический ключ – позволяет более комфортно провести процесс разблокировки смартфона, но надежность такой защиты ниже, чем парольной.
• Сканер отпечатков пальцев – использует биометрические особенности наших пальцев. Самый удобный, при условии, что удачно реализован в смартфоне, и достаточно надежный способ снятия блокировки экрана. Чтобы его взломать преступнику придётся провести довольно сложные манипуляции, требующие времени и специального оснащения. Сканер отпечатков пальцев мы детально рассматривали в одной из наших статей. Напомню лишь, что его нативная поддержка появилась только в Android 6.0.
• Начиная с пятой версии Android появилась нормально работающая функция Доверенное лицо, которая разблокирует смартфон только если узнает Вас в лицо. Также можно задать Доверенное место, например, в вашей квартире телефон будет постоянно разблокирован.
• Также нововведением Android 5.0 стала возможность снятие блокировки экрана через Bluetooth или NFC. Осуществить это можно с помощью, например, смарт-часов. Удобно, но в вопросе безопасности имеет некоторые уязвимости.
  

1.2 Шифрование данных. Впервые появилось в Android 4.3, где пользователь мог ее по желанию активировать. В Android 5.0 Lollipop она же задействована по умолчанию. Шифрование данных привязывается к паролю или ПИН-коду на снятие блокировки экрана смартфона – как только вы его ввели происходит дешифровка данных. Также пароль будет запрошен при включении устройства. Полезность шифрования состоит в том, что у злоумышленника может иметь возможность считать ваши данные не снимая блокировку экрана. Также вы можете зашифровать и внешнюю SD карту.

1.3 Удаленное управление. Функция безопасности Android, позволяющая найти потерянный или украденный смартфон (должна быть включена геолокация), а если это сделать невозможно, то — удаленно стереть все свои данные.

По умолчанию эта возможность отключена, активировать ее нужно самостоятельно.

1.4 KNOX – система политики безопасности, которая предусматривает разделение информации на личную и рабочую, централизованный контроль и аудит, удаленный поиск и блокировку устройства и т.п. Разработка компании Samsung , ориентированная в основном на корпоративных пользователей. В пятой версии Android были использованы некоторые API KNOX

Пользование специализированного ПО

Еще один хороший способ защитить свой смартфон от кражи, потери личной информации и взлома состоит в установке сторонних приложений – антивирусов, файрволов, антиворов. Их существует великое множество платных и бесплатных, с разным функционалом.

Правильная настройка политик безопасности

Особенностью системы безопасности Android является то, что любое приложение должно задекларировать все права доступа к функциям системы, на которые она претендует. Это может быть разрешение на использование интернета, СМС, голосовых вызовов, камеры и т.д. Если же такие привилегии не прописаны в инсталляторе приложение, то и доступ к ним будет запрещен. И перед установкой программы пользователь в обязательном порядке должен ознакомится и согласиться со списком этих прав. В Android 6.0 Marshmallow добавлена нова функция безопасности, которая позволяет разрешить или запретить доступ к системе непосредственно перед выполнением приложения.

Общие рекомендации по повышению уровня безопасности Android

Подытоживая все вышесказанное, хочу дать пару советов, как защитить свой смартфон и информацию в нем:

• придумывайте сложные пароли, не менее восьми знаков состоящие из букв, цифр и других символов. Также это не должны быть слова, используемые в речи, так как такие пароли подбираются с помощью словаря;
• приложения устанавливайте только из проверенных источников. Перед установкой почитайте отзывы о софте. Внимательно изучите и проанализируйте список привилегий, которых просит приложение;
• установите дополнительно антивирус, антивор и т.п.;
• не подключайтесь к сомнительным  Wi-Fi сетям, так как они могут быть использованы злоумышленниками для перехвата ваших данных;
• вовремя обновляйте версию операционной системы – в апдейтах устраняются уязвимости и вводятся новые функции безопасности;
• не пренебрегайте шифрованием данных;
• удаляйте ненужные приложения, не захламляйте смартфон.
• отключите режиме отладки в настройках
• не устанавливайте неофициальные прошивки
• не передавайте свой смартфон мало знакомым людям, не оставляйте их в серсвисах, если в памяти телефона содержится конфиденциальная информация
  

Всем спасибо!

Берегите себя, своих близких и свои гаджеты!

Безопасность Android-приложений. Лекция в Яндексе / Яндекс corporate blog / Habr

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

Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.

Я бы выделил следующие источники проблем. Первые — сетевые, связанные с коммуникацией с сервером. Это когда ваши данные передаются не совсем защищенным способом. Вторые связаны с проблемой хранения данных: это когда ваши данные хранятся где-то в открытом виде, могут даже где-то на SD-карте храниться, либо они не зашифровываются, в общем, когда к ним есть доступ извне.

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

В этом докладе мы остановимся именно на третьем виде проблем, связанном с воздействием сторонних приложений. Мы рассмотрим не только теорию, но ещё и конкретные примеры из реально существующих приложений. Причем некоторые эти примеры до сих пор актуальны, видимо, на них просто забили, но мне они кажутся достаточно интересными.

Этот доклад будет полезен тем, кто занимается Android-разработкой. Я бы советовал уделить внимание этим аспектам всем, кто делает приложения. Например, тестировщикам. Тестировщики, мне кажется, если посмотрят эти нюансы, смогут какие-то премии выбивать, они начнут более глубоко вникать в разработку, даже программировать можно особо не учиться. Manifest-файл просто смогут анализировать и выявлять потенциально опасные места. И всем остальным, кто интересуется такими вопросами безопасности.

Прежде чем начнем, стоит упомянуть софт, который может пригодиться. В первую очередь BytecodeViewer, очень полезная программка, позволяет одним кликом получить из apk-файла все исходники, все ресурсы, в том числе manifest-файл.

Стоит отметить удобную утилиту для Android — ManifestViewer. Она позоляет очень быстро просматривать manifest-файлы всех установленных приложений. Я её использую по работе, например, когда ко мне приходят и говорят: аккаунт-менеджер не работает, что такое? В первую очередь всегда смотрю manifest-файл, чтобы убедиться, что аккаунт-менеджер был правильно интегрирован, то есть что все его компоненты объявлены как надо.
Эта программка полезна, чтобы вы на скорую руку открыли и посмотрели точки входа, вектор атак из manifest-файла.

Если вы любите всё делать из консоли, вот вам все эти программы отдельно. apktool позволяет выдернуть все ресурсы и manifest-файл. Dex2jar и enjarify позволяют конвертировать apk-файл в jar. Dex2jar может какие-то apk не конвертнуть, выдать с каким-то исключением. Не отчаивайтесь: часто такие файлы скушает enjarify, и вы получите jar. Это две хороших утилиты.

После того, как у вас есть jar-файлы, вы можете взять Java Decompiler и сконвертировать их в более удобный вид — в вид классов. Понятно, что их нельзя будет запустить, но анализировать их гораздо проще, чем код, который там получается, и т. п.

Давайте рассмотрим самые базовые проблемы. Во-первых, сначала нам нужно проанализировать manifest-файл, потому что в нем обязательно должны быть описаны все компоненты Android-приложения. Это Activity, Service, Broadcast Receiver, ContentProvider. Все они, за исключением Broadcast Reciever, обязательно должны там находиться.

Поэтому когда мы начинаем поиск каких-то проблем, мы смотрим эти компоненты. Вот конкретный пример. Это сервис, который был объявлен в manifest-файле одного приложения, он явно экспортируется. В нем даже явно указано, что он экспортирован. Это означает, что он доступен любому другому стороннему приложению. Любое другое приложение, в свою очередь, может послать в этот сервис интент, и сервис может выполнить какие-то действия, если они там предусмотрены.

В данном случае мы видим потенциальный вектор для атаки. Если копнем глубже и посмотрим исходники, по ним станут понятно, что этот сервис позволяет, допустим, удалить авторизованного пользователя в этой программе. Я сомневаюсь, что разработчики предусматривали такую фичу для каких-то сторонних приложений. Это конкретный пример, которому следует уделить внимание.

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

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

Что делало это событие? Оно обрабатывалось при помощи публичного BroadcastReciever. То есть злоумышленник тоже мог послать любой бродкаст — подобрать ID письма и, допустим, удалить его. Причем необязательно, чтобы это было сообщение в панели.

Когда-то давно в Яндекс.Почте была такая уязвимость. Уже всё поправили, так что можно пользоваться, всё отлично. Спасибо Ильдару, они оперативно всё это делают.

Как это решилось? Компоненту просто сделали недоступной извне, поставили ещё permission дополнительно. Его можно было и не ставить, главное — если она не экспортируется, значит, уже никто не сможет к ней подключиться и что-то выполнить.

Следующий вид проблем — использование неявных интентов, когда в интенте не задается конкретное место, в которое он должен прийти. Это означает, что у вас нет гарантии, что этот интент придет туда, куда вы хотите. Он может прийти куда-то ещё. Поэтому тут надо быть внимательным.

Ещё нюанс, который я отнес бы к неявным интентам, — это Browsable Activity, когда у нас из браузера можно открыть Activity стороннего приложения. Это происходит, когда задана какая-то схема, хост, там кликают и у вас открывается окно. Хорошо, когда просто открылось окно и например, передалась позиция на карте. Это не страшно. А страшно — следующее. Допустим, у нас некоторые ребята предлагают использовать Slack в компании. В Slack очень интересная авторизация. Если вы авторизовались в браузере на Android, то вы можете авторизоваться и в установленном приложении Slack. Это работает по такой схеме, когда в браузере есть URL, вы по нему кликаете и его перехватывает приложение Slack.

Но здесь нет гарантии, что URL не перехватит кто-то другой, причем по нему передается токен. Схема достаточно простая: когда вы кликаете в браузере, вас сразу авторизовывают в приложении Slack. Значит, этого URL достаточно для авторизации.

Здесь отмечены кнопки, которые можно кликать в браузере и которые инициируют это открытие. Это не только «Открыть Slack», но и логотип — он всегда находится сверху, на любом экране.

Давайте посмотрим видео, которое демонстрирует использование этой проблемы. Мы авторизовались, зашли в свою директорию, нажали на логотип Slack — но приложения Slack у нас нет, у нас злоумышленник подставил интент-фильтр. Вернулись, нажали… Можно фишинг сделать — точно такой же по внешнему виду, как Slack. Написать, что авторизация не сработала и всё такое. Пользователь ничего не поймет, а токен окажется у вас. Поэтому если пользуйтесь Slack, то будьте внимательны с этой браузерной авторизацией.

Решение очень простое. Как говорил мой коллега, можно использовать явные интенты, которые открываются из браузера. Но когда я в Slack зарепортил и мой тикет получил номер 80000 с чем-то, они сказали, что это дубликат и что уже есть тикет 50000-какой-то. Если прикинуть, получится, что им это больше чем полгода назад сообщили. Исправляется вроде достаточно просто, но — не исправили. Значит, это не критичная проблема и можно тогда о ней рассказать.

Здесь есть рекомендация, что лучше всегда использовать явный интент. Если вы почитаете и вникнете более глубоко, то узнаете, что у Android была прикольная опечатка. Они в одном месте использовали неявный pending intent. Из-за этого можно было получить доступ к пользователю с правами system. Они эти ошибки исправили в Android 5. Такие ошибки у всех бывают, даже у Google.

Всегда лучше использовать явный интент или, если это невозможно, всегда задавать какой-то permission. Он позволяет ограничить доступ.

Рассмотрим другой вид уязвимостей — основанный на пользовательских данных.

У нас есть приложения, которые могут получить какие-то данные от пользователей, например отправить какой-то файл, открыть его, просмотреть. Это обычно осуществляется при помощи интентов типа view и send.

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

Можно взять getAbsolutePath() и проверить, совпадает ли директория с вашей приватной. Но это неправильно.

Вам злоумышленник может прислать не сам файл, а ссылку на него.

Как может создаваться эта ссылка? У злоумышленника создается readme.txt — он сделал ссылку на приватный файл вашего приложения. Затем он запихнул эту ссылку вам, и если вы будете использовать getAbsolutePath(), то вам вернётся путь ссылки — путь к файлу readme.txt. А вы подумаете, что всё нормально.

Чтобы это исправить, лучше использовать метод getCanonicalPath(). Он возвращает полный путь, самый настоящий. В данном случае система вернет не readme.txt, а какой-нибудь mailbox. Учитывайте эти проблемы.

Я сталкивался с ситуацией, когда подобная проблема была у одного приложения более чем с 50 млн пользователей. Говоришь: покажите мне этот файл. Они его кешируют на SD-карту и потом пытаются открыть. Так можно было все токены украсть. Они уже всё исправили, но попросили пока не разглашать. Тем не менее, такое встречается.

Следующий интересный момент: вам могут прислать ссылку на content provider, и он тоже может быть передан. Даже если он защищен через permission, даже если он не экспортируемый, то всё равно — когда ваше приложение попытается его открыть, выполнится метод query, который есть в content provider.

Тут надо быть осторожным. Вот ещё один реальный пример, уже из другого приложения. Они делали бэкап БД из метода query. Туда можно было передать action типа backup и программа сразу дублировала всю БД на SD-карту. Получается, вроде провайдер защищен, но его можно так подсунуть, чтобы получить в итоге всю БД.


Я больше нигде не встречал, чтобы кто-то делал запись в методе query, но там всегда лучше открывать что-то для чтения. А ещё — учитывать, что там может быть SQL-инъекция. Сейчас есть ряд приложений, в которых я обнаружил возможность SQL-инъекции. Однако доступы у них только для чтения, и я пока не понял, можно ли там дальше что-то сделать. Но вдруг найдется уязвимость в самой БД SQLite, которая позволит выполнить уже не настолько безобидную инъекцию? Всё-таки лучше их не допускать, даже если если при открытии есть доступ только для чтения.

Теперь давайте рассмотрим одну проблему с WebView, причем срабатывает она во всех Android до версии 5.0 и позволяет обойти SOP. Из этого мы сделаем вывод, что в WebView лучше никому не давать открывать свои файлы.

Рассмотрим этот вид атаки. Зловредное приложение может попросить ваше приложение, если оно имеет доступы к WebView: покажи мне файлик index.html. Предположим, ваше приложение открыло index.html. Содержимое файлика очень простое — JavaScript, который через 5 секунд сам файлик, самого себя, загружает в iframe, перезагружает как бы.

В этот период времени зловредное приложение указанный файлик удаляет и заменяет на символическую ссылку на приватный файл из вашего приложения. Проходит 5 секунд, оно перезагружается, но контент в нём уже становится контентом того самого приватного файла. На Android до 5.0 ещё до WebView, видимо, стоит неправильная проверка на то, что это символическая ссылка. Таким образом можно прочитать контент. Оно смотрит — имена файлов совпадают, значит SOP не нарушена, контент можно отдать и значит, JavaScript может взять контент и отправить его на сервер.

Такой вид атаки встречается не только в WebView. Он до сих пор работает в UCBrowser, у которого больше 100 млн установок. Я встречал такое и на некоторых версиях Android-браузера, до Android 5.0. Наверное, он тоже на WebView построен. Например, на телефонах Samsung у меня такое не получилось воспроизвести, а на моем телефоне Acer срабатывает.

Глянем небольшое видео о том, как это работает в UCBrowser. Речь о небольшом зловредном приложение, но оно может сработать. Вы легли спать, телефон тоже, внезапно запускается activity, страничка. Вы спите, а там запустилось — какой-то iframe, подтверждение, алерт. Если алерт прочитал контент, значит, мы точно так же могли отправить этот контент куда угодно. Это bookmark.db, тут хранятся закладки. Думаю, кому интересно — может поисследовать. Возможно, удастся найти там более приватные пользовательские данные. Можно и куки украсть. Но куки у них названы по имени сайта, поэтому надо перебирать. ВКонтакте можно взять. Уязвимость до сих пор есть, вроде пока ещё не исправили и не спешат исправлять.


Вывод: если у вас есть WebView, то не давайте никому открывать в нём свои ссылки. А если всё-таки даёте, то хотя бы запретите открытие локальных файлов. В этом плане большие молодцы компания Qiwi, я их приложение пробовал, обрадовался, что сейчас открою файлик — ан нет, они запретили открывать локальные файлы и ничего не сделаешь.

Рассмотрим следующий вид нетривиальной проблемы. Она основана на особенностях десериализации в Android. Возможно разработчикам самой Java может быть полезно.

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

Есть в Android до 5.0 такой бонус: на некоторых версиях при десериализации не проверяется, что класс действительно имплементирует интерфейс сериализации.

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

Итак, что тут опасного? Если объект был создан, он когда-нибудь будет удален. Обычно в том, что метод finalize вызовется, нет ничего опасного, ничего не реализуется. Однако когда есть нативная разработка, то обычно в методе finalize вызывают деструктор из нативной области и передают туда указатель. Я нативной разработкой не занимался, но поизучал, как туда передаются указатели. Если данный указатель сериализуется, то злоумышленник может подставить свой, а он, в свою очередь, может как вызвать ошибку выхода за границы памяти, так и указать на другую память, которая потом возьмет и выполнит какой-то код.

Этим воспользовались ребята из компании IBM. Они проанализировали весь список классов на платформе Android — проверили больше тысячи или сколько их там. И нашли всего один, который удовлетворял критериям: он был сериализуемый, и он сериализовал native-указатель. Они взяли этот класс, подставили свой указатель, он сериализовался и десериализовался. Он был новым не каждый раз. Сделали proof of concept, демонстрацию, есть видео. Эта уязвимость позволила им при помощи этого класса заслать интент в системное приложение. Оно позволило им, допустим, удалить оригинальное приложение Facebook и заменить его на фейковое. Видео длится минут 7. Там приходится повертеть — пока finalize вызовется, пока очистится память. Но вывод — никогда не надо десериализовывать нативный указатель.

Подытожим. Лучше никогда не экспортировать компоненты, которые есть в вашем приложении. Либо — ограничивать доступ по permission. Интенты всегда лучше использовать явные, либо permission задать. Никогда не доверяйте тем данным, которые придут от пользователя — это могут данные на что угодно, даже на ваши приватные области. Вы их потом можете повредить. Внимательно отнеситесь к ContentProvider, в том числе к SQL-инъекции и т. п.

Такая штука, как WebView, — она вообще не для игрушек. Если она есть в вашем приложении, закройте её и никому не давайте с ней играться.

Сериализация, а точнее, нативная разработка — это тоже как спички, будьте с ней поосторожнее. Спасибо за внимание.

Security-приложения для Android-смартфонов | Блог Касперского

Безопасность — это не только защита от вирусов. Это и защита данных от посторонних глаз, и ограничение прав «нахальных» приложений, резервное копирование на случай порчи смартфона, и черный список нежелательных абонентов, и шифрование, и родительский контроль. Android очень гибок, поэтому все эти задачи можно решить, установив из Google Play нужное  приложение. Правда, на каждый случай выбор огромен, и мы решили упростить вам задачу, подыскав лучшие приложения.

Парольная защита приложений и мультимедиа
Бесплатно/есть premium-функции
Почти все приложения на смартфоне считают, что человек, который взял устройство в руки, — владелец. В жизни это не так. Телефон могут взять друг — «просто посмотреть, что у тебя там», дети — поиграть, коллеги или родственники — сунуть свой нос без спроса. В последнем случае поможет включение графического ключа или кода блокировки, а вот выдавая смартфон друзьям или детям, его приходится разблокировать. И дальше все ваши личные данные всего в одном клике от просмотра посторонними. App Lock решает эту проблему, создавая список защищенных приложений. При их запуске придется ввести дополнительный пароль.
Кроме того, возможно перенести особо важные фото и видео в защищенную паролем медиагалерею,  сохранив менее важные фото в обычном месте. Для особо скрытных App Lock умеет прятать себя, тогда активировать настройки приложения придется секретным «номером телефона».

 

Изъятие разрешений у приложений
Бесплатно
При установке любого приложения Android предупреждает, какие разрешения ему требуются. Увы, узнав, что живым обоям нужен доступ к вашим контактам и отправке SMS (кстати, это плохой признак, и не стоит их устанавливать), вы ничего не можете сделать, кроме как отказаться от инсталляции. И все больше приложений требуют «лишние» разрешения. У Google, оказывается, есть инструмент, позволяющий избирательно отозвать часть разрешений у уже установленного приложения. Он появился в Android 4.3 и называется App Ops. К сожалению, в версии 4.4.2 его снова скрыли с глаз долой. Данное приложение App Ops просто дает доступ к экрану настроек Google, где можно запретить приложению читать контакты, следить за вашим местоположением и так далее.
Для Android 4.4.2 и старше, к сожалению, чтобы это работало, требуется root-доступ. Для Android младше 4.3 App Ops не работает, но аналогичную функцию выполняет приложение LBE Privacy Guard.

Скрытая функция #Android — отозвать разрешение у установленного приложения. Можно, например, запретить GPS-слежку за собой

Tweet

 

Шифрование данных на смартфоне
$8
Для тех, кто вынужден хранить на смартфоне конфиденциальные документы, всякого рода «замки» вроде App Lock и PIN-коды разблокировки не являются достаточной защитой. Начиная с Android 3.0 операционная система позволяет зашифровать все данные в памяти смартфона. Этот процесс надежно защищает данные, но каждый раз для разблокировки придется вводить полноценный пароль (иначе вся затея теряет смысл). Вводить пароль 50 раз в день утомительно, поэтому есть альтернатива — зашифровать только те файлы, которые по-настоящему важны. Для этого нужно специальное приложение, такое как EDS. Оно создает на карте памяти файл-контейнер, все данные в котором тщательно зашифрованы. Положив свой документ в контейнер, вы защитите его от посторонних.
В EDS есть два режима работы. В более простом все операции с контейнером производятся вручную. В более сложном и требующем root-доступа зашифрованный контейнер, когда он подключен, выглядит как еще один съемный диск в системе. Просто сохранив на диск документ, вы его шифруете. Важный нюанс — контейнеры EDS совместимы с популярным настольным приложением TrueCrypt, что упрощает обмен данными с компьютером.
Данное приложение рекомендуется для частных пользователей, в то время как компаниям и их сотрудникам рекомендуется установить специальную MDM-систему, решающую вопросы мобильной безопасности в комплексе.

 

Родительский контроль за подростками
$20/одно устройство
В зависимости от возраста детей приложение «родительского контроля» должно работать принципиально по-разному. Для подростков оптимальная модель такова: устройство находится в распоряжении ребенка, и родители лишь дистанционно устанавливают определенные ограничения, например запрет на посещение порносайтов или максимальную длительность ежедневных игр. В Google Play есть десяток подобных приложений, но многие из них попросту не работают по тем или иным причинам. Funamo Parental Control выполняет заявленную функциональность: блокировку веб-сайтов по заданным ключевым словам и адресам, запрет внутриигровых покупок, принудительное включение безопасного поиска (Safe Search) на Google, Bing и Yahoo!, ограничение на запуск определенных приложений (по времени суток, продолжительности работы и т.п.). Также через веб-панель управления доступен дистанционный мониторинг — GPS-положение, чтение SMS, истории посещения веб-сайтов и так далее. Основным недостатком приложения является отсутствие фильтрации по категориям контента (насилие, политика, порно и так далее), как это сделано в Windows-версии Kaspersky Internet Security и Kaspersky Safe Browser.
Стоит отметить, что скрытный мониторинг невозможен, поскольку приложение всегда выводит свою иконку в панели оповещений. Поэтому родителям придется обсудить эту тему с детьми и установить приемлемые правила пользования смартфоном.

 

Скрытие части фото и видео
Бесплатно/есть premium-функции

Предупреждение: эта и подобные программы пока что работают ненадежно на Android 4.4 (KitKat). Пользователям 4.4 рекомендуется сделать резервные копии фотографий и аккуратно проверить, что функции «Скрыть/показать» работают корректно.
Чуть ли не на половине смартфонов в фотогалерее есть снимки, которые лучше не видеть посторонним. Простой способ скрыть их, не удаляя, — Gallery Lock. Выбранные снимки удаляются из обычной галереи и помещаются в специальную, защищенную паролем. Для самых скрытных есть функция «Стелс», в этом режиме иконка Gallery Lock пропадает и запустить секретную галерею можно, лишь набрав цифровой код в приложении «Телефон».
Для тех, кто хочет так же скрывать контакты, вызовы или переписку, есть специальная функция в Kaspersky Internet Security для Android.

 

Защита от воров, вирусов, жуликов и любопытных
Бесплатно/есть premium-функции
Конечно, Kaspersky Internet Security  для Android защитит вас от мобильных вирусов и посещения опасных сайтов (например, фишинговых), но это далеко не единственная полезная функция приложения. Даже бесплатная версия оснащена богатыми «противоугонными» возможностями. Забытый смартфон можно найти, включив на нем сирену, заблокировать дистанционно или стереть с него всю информацию, а также можно найти его по GPS или сфотографировать того, кто нашел (украл?) смартфон.
Кроме того, можно скрыть в записной книжке и SMS часть контактов, делая общение с ними незаметным для тех, кто получил физический доступ к телефону. Также предусмотрен черный список, люди из которого не смогут вам звонить и писать.
Ну а возвращаясь к вредоносному ПО, отметим, что по результатам недавнего независимого теста Kaspersky Internet Security для Android показал 100-процентный уровень защиты от вирусов (а их для Android только с начала года написано более 100 тысяч).

 

Детский режим на смартфоне
Бесплатно
В названии приложения фигурирует «родительский контроль», и это несколько неверно. Более правильно говорить о детском режиме, в котором смартфон, принадлежащий родителю, выдается ребенку. В детском режиме смартфон не принимает и не отправляет телефонные вызовы, запрещает запуск приложений, кроме тех, что входят в список дозволенных, предотвращает покупки и установку новых приложений. В общем, играть можно, пользоваться нельзя. Удобно!

 

 

Менеджер паролей
Бесплатно/$12 в год
Многоплатформенный менеджер паролей позволяет вести единую «облачную» базу данных на компьютере и смартфоне. Отключение рекламы и дополнительные функции требуют ежегодной оплаты. Благодаря LastPass к каждому сайту можно иметь уникальный и сложный пароль, не слишком напрягая память. По сравнению с многочисленными конкурентами LastPass интересен тем, что вход в сам менеджер можно защитить двухфакторной аутентификацией.

 

 

Резервное копирование смартфона
Бесплатно/есть premium-функции
Хотя резервное копирование отчасти реализовано в самом Android и при правильной настройке вы не потеряете ни контакты, ни купленные приложения, при смене смартфона вам все равно придется делать целый ряд трудоемких настроек, например заново выносить нужные иконки на рабочий стол. Также некоторые данные, например список вызовов и SMS, не охвачены копией Google. Приложение MyBackup старается скопировать (а потом восстановить) каждую мелочь на вашем смартфоне: плей-листы в плеере, имена точек доступа Wi-Fi, личный словарь на клавиатуре, настройки каждого приложения и т.п.
Копию можно сделать как на SD-карту, так и в «облако» MyBackup. Ряд функций требуют root-доступа. По сравнению со знаменитым Titanium Backup приложение отличается большей функциональностью, доступной без root.

 

Tor project для Android
Бесплатно
Ставшая знаменитой система анонимного зашифрованного доступа в Интернет Tor доступна и на смартфонах. Правда, лишь на Android. Приложение позволяет спрятать за цепочкой «луковых роутеров» содержимое ваших коммуникаций, и это доступно для любого другого приложения на смартфоне, лишь бы оно поддерживало настройку доступа через прокси-сервер. Также создатели рекомендуют целый комплект дополнительных программ, которые оптимально интегрированы с Orbot и обеспечивают повышенную анонимность пользователю: Orweb, Gibberbot, DuckDuckGo и т.п.

Новая броня Android. Как Android 9 будет защищать приватность и безопасность пользователей

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

Восьмого марта Google представила предварительный выпуск Android P, который почти со стопроцентной вероятностью вскоре сменит имя на Android 9. В новой версии в очередной раз изменился интерфейс, появились новые функции панели уведомлений, поддержка HDR, двух камер, но наше внимание, как всегда, привлекает нечто гораздо более интересное: безопасность и новые механизмы ограничений.

 

Запрет на фоновое использование камеры и микрофона

Об одном из самых заметных security-новшеств Android стало известно еще до выхода превью Android P, писали о нем и мы. Это, конечно же, запрет на использование камеры, микрофона и любых сенсоров приложениями, которые находятся в состоянии Idle, то есть свернуты и работают в фоне. Так что разного рода малварь, которая любит снимать и слушать происходящее вокруг, теперь должна отвалиться.

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

Для этого Google в очередной раз предлагает использовать так называемый foreground service. Это специальный тип фоновой службы, которая имеет уведомление в панели уведомлений, а потому заметна пользователю. Никто не мешает тому же пользователю скрыть это уведомление стандартными средствами.

 

Запрет на cleartext HTTP

Второе важное нововведение Android P — полный запрет на использование HTTP без TLS (то есть без шифрования) для всех приложений, собранных для новой версии Android. Другими словами, если в build.prop приложения указан targetSdkVersion больше 27, то приложение не сможет подключаться к хостам по HTTP.

Это ограничение тем не менее можно обойти, если указать в файле настроек безопасности сети (network_security_config.xml) список разрешенных доменов:

<domain-config cleartextTrafficPermitted="false">
    <domain includeSubdomains="true">secure.example.com</domain>
</domain-config>

 

Шифрование резервных копий

Пока эта функция еще не активирована, но в следующих выпусках Android P можно будет указать пароль, без которого невозможно восстановить резервные копии настроек приложений, автоматически отправляемых в Google Drive. Это в том числе означает, что даже у Google не будет доступа к твоим данным. Apple, кстати, всегда имела доступ к резервным копиям и отдавала их властям по первому же запросу.

 

Диалоги подтверждения с защитой от MITM

Еще одно интересное нововведение Android P — доступный сторонним разработчикам «защищенный» диалог подтверждения (ConfirmationDialog). Он позволяет удостовериться, что пользователь действительно увидел текст диалога и согласился с ним, даже в том случае, если смартфон пользователя был взломан и малварь получила контроль над ядром и фреймворком.

Если пользователь положительно отвечает на сообщение диалога, приложение получает криптографическую подпись, защищенную кодом аутентификации сообщения с ключом-хешем (HMAC). Подпись создается доверенной средой исполнения (TEE), которая защищает диалоговое окно и ответ пользователя. Подпись означает, что пользователь действительно увидел сообщение и согласился с ним.

 

Запрет на использование скрытых API

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

В Android P доступ к скрытым API запрещен. Более того, новая версия Android выводит уведомление в том случае, если приложение использует объявленные устаревшими (deprecated) API. Это должно заставить разработчиков перейти на использование новых API.

 

Криптографический модуль StrongBox

Некоторые из устройств, оснащенных Android P, могут иметь встроенный криптографический модуль StrongBox, работающий в кооперации с модулем TEE (Trusted Execution Environment, например, TrustZone в процессорах Qualcomm). По сути, этот модуль — реализованный в железе Keymaster HAL (Hardware Abstraction Layer), который в текущих версиях ОС представляет собой библиотеку, реализованную производителем устройства или чипсета.

Как происходит работа с Keymaster

 

Реализация OMAPI API

Android P поддерживает GlobalPlatform Open Mobile API (OMAPI API), предназначенный для доступа к защищенным элементам (Secure Elements, SE), специальным микрочипам, которые обычно устанавливаются в SIM-карты, банковские карты, карты оплаты проезда и смартфоны с поддержкой бесконтактных платежей.

Secure Element — отдельный микропроцессор с собственной памятью. Он отвечает за безопасное хранение и выполнение платежных приложений. В смартфонах с поддержкой NFC SecureElement обычно впаян в материнскую плату, но также может находиться SIM-карте или даже в карте памяти.

 

Одной строкой

• Начиная с Android P приложения больше не смогут прочитать серийный номер устройства через переменную Build.SERIAL. Она всегда будет равна UNKNOWN. Для получения серийного номера теперь нужно полномочие READ_PHONE_STATE.
• Появилась нативная поддержка высокопроизводительного поточного шифра ChaCha20, который в том числе используется в браузере Chrome при соединении с сайтами Google, в ядре Linux для генерации случайных чисел и в некоторых системах потокового вещания.
• Правила SELinux теперь запрещают приложениям делиться данными с другими приложениями путем выставления открытых прав доступа на файлы.
• В следующих выпусках Android P планируется включить поддержку рандомизации MAC-адресов при сканировании Wi-Fi-сетей. Это позволит бороться с отслеживанием пользователей (в iOS такая функция встроена еще с версии 8).

 Загрузка …

10 советов по безопасности Android, которые нужно знать

Превратите свой смартфон в настоящий Форт-Нокс

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

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

Предлагаем вашему вниманию 10 советов по безопасности, которые помогут вам использовать смартфон на базе Android максимально безопасно.

1. Используйте менеджер паролей

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

Менеджер паролей, такой как LastPass, может прийти на помощь. Менеджер хранит ваши пароли, для доступа к которым нужно ввести еще один, его то и стоит запомнить.

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

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

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

2. Не загружайте приложения из неизвестных источников

Гибкость системы Android является одним из главных ее преимуществ над iOS. Однако, такая свобода может и навредить смартфону, если устанавливать приложения из неизвестных источников.

Android позволяет пользователям устанавливать приложения посредством установщика, также как и на ПК. Можно скачать apk-файл из браузера или из других источников, например, Getjar или SlideMe.

Таким способом удобно распространять еще не финальные версии приложений или тех, которые по каким-либо причинам не были одобрены в Google Play. Простого способа узнать о наличии вирусов в файле нет, поэтому стоит пользоваться только официальным магазином Google Play.

3. Не используйте легкие сочетания, вроде «1234» в качестве PIN-кода

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

Если вы используете сканер своего телефона, важно, чтобы ваш резервный PIN–код не был слишком легким, например – 1111, 0000 или 1234. Такие сочетания не подходят для паролей, и их использование своди на нет всю безопасность.

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

4. Не отправляйте конфиденциальные данные через общие сети Wi-Fi

Живя в крупном городе, довольно трудно избежать использования общественного Wi–Fi. сеть повсюду, и многие из них от одних и тех же провайдеров. Специалисты по безопасности советуют быть более внимательными и стараться избегать общедоступный Wi-Fi вообще.

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

Лучше всего просматривать сайты только с URL-адресом – «https», так будет безопасно. И никогда не вводите данные своей карты и не используйте онлайн-банкинг в общих сетях Wi-Fi. Все банковские сайты могут быть защищены, но эта безопасность не сможет противостоять так называемой «атаке через посредника», когда хакер перехватывает информацию, отправляемую с вашего телефона на банковский или другой сайт.

5. Попробуйте использовать VPN

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

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

Лучшими VPN сервисами являются: Tunnelbear, NordVPN b ExpressVPN.

6. Проверяйте обновления безопасности

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

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

Обновление для системы безопасности.

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

Частота обновлений безопасности должна учитываться при покупке смартфона. Телефоны от Google, такие как Pixel 3, получают обновления безопасности первыми, а устройства Android One гарантируют не менее трех лет поддержки обновлений безопасности.

7. Обновляйте приложения

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

Чтобы проверить наличие обновлений, перейдите в Google Play, выберите Мои приложения и игры, а затем вкладку Обновления.

Включите автоматическое обновление, чтобы быть уверенном в актуальности версий установленных приложений. Вы найдете опцию автоматического обновления в Настройки > Автоматическое обновление.

8. Используйте двухэтапную аутентификацию

Лучший способ избежать взлома аккаунта Google – использовать двухэтапную аутентификацию. Когда вы включите эту функцию, код будет отправляться на телефон при попытке войти в учетную запись на другом устройстве.

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

Вы можете включить бесплатную двухэтапную аутентификацию от Google на специальном сайте. Всякий раз, когда вы входите в систему вы можете выбрать- использовать SMS оповещения или приложение Google для подтверждения.

9. Включите удаленную блокировку и сброс данных

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

Для доступа к функции, дайте доступ к определению местоположения в настройках безопасности и в том же меню включите функцию «найти телефон».

10. Будьте внимательны при переходе по ссылкам в SMS-сообщениях

Мы знаем много людей, которые, будучи достаточно осведомленными, все равно страдали от SMS мошенничества. Классические примеры включают в себя тексты, якобы, из вашего банка, где просят входа в ваш аккаунт. Также распространена афера через WhatsApp, где вас просят заплатить небольшую сумму, чтобы продолжить использование сервиса, и ввести данные своей карты.

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

Однако есть приложения, например, Kaspersky Internet Security, которые сканируют тексты на наличие угроз фишинга.

Как сделать Android максимально безопасным

Мобильная безопасность — это большая проблема, возможно, сейчас больше чем когда-либо. Большинство из нас «живет» в телефонах, с финансовой информацией, календарными встречами, семейными фотографиям, хранящимися на наших устройствах. Вот как обеспечить безопасность телефона Android.

Включить двухфакторную аутентификацию в своей учетной записи Google

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

Если Вы еще этого не сделали, начните с включения двухфакторной аутентификации (2FA) в своей учетной записи Google. Существует несколько вариантов этого второго фактора, будь то простое текстовое сообщение (которое по своей сути является наименее безопасным из всех методов 2FA, но все же лучше, чем ничего) для добавления ключа U2F, такого как набор инструментов Titan Key от Google.

Настройки Google 2FA можно найти в разделе «Моя учетная запись» > «Двухэтапная аутентификация» (и Вам обязательно нужно будет войти в систему).

Кроме того, пока Вы заглядываете в свои настройки учетной записи Google, вероятно, стоит пойти и запустить проверку безопасности. Это позволяет добавлять или изменять номера телефонов восстановления или адреса электронной почты, проверять последние события безопасности, просматривать, какие устройства регистрируются (и удалять их, если необходимо), и многое другое.

Используйте блокировку экрана

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

Хотя процесс немного меняется между производителями Android и их различными прошивками, общий смысл такой — «Настройки»> «Безопасность»> «Блокировка экрана». Как мы уже сказали, детали могут немного отличаться здесь, но это приведет Вас в нужное место. У нас также есть более подробное руководство, если вам это нужно.

И не забудьте добавить свой отпечаток пальца, если на Вашем телефоне есть сканер.

Убедитесь, что «Найти устройство» включено

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

К счастью, у Google есть система отслеживания для телефонов Android. Она называется «Найти устройство», и она должен быть включен по умолчанию на всех современных телефонах Android. Чтобы проверить, перейдите в Настройки > Google > Безопасность > Найти устройство.

Если Вы когда-нибудь потеряете свой телефон или его украдут, Вы можете запустить веб-браузер и найти в Google «Найти устройство» и удаленно найти потерянное устройство. Мы более подробно рассмотрели все, что Вы можете сделать, с помощью «Найти устройство», если это Вас интересует.

Отключить «Неизвестные источники» и режим разработчика

Если раньше Вы использовали свой телефон, Вы могли бы включить что-то под названием «Неизвестные источники» (или «Установить неизвестные приложения» в новых версиях Android). Этот параметр позволяет устанавливать приложения, не входящие в Google Play Store. И хотя Oreo сделал все возможное, чтобы сделать эту функцию более безопасной, по-прежнему опасно оставлять ее включенной.

Чтобы повысить безопасность, Вы должны отключить эту функцию. В версиях Android до версии Oreo (8.0) Вы можете сделать это легко в Настройках > Безопасность > Неизвестные источники. В Oreo (8.0) и Pie (9.0) Вам нужно отключить эту функцию для каждого приложения, но Вы можете найти все, что имеет доступ к этой функции в Настройках > Приложения > Специальный доступ > Установка неизвестных приложений.

Аналогично, если Вы когда-либо включали режим разработчика по какой-либо причине, но не активно полагались на какие-либо функции, то отключите его. Перейдите в Настройки > Режим разработчика и сдвиньте переключатель в положение «Выкл».

Примечание: На Android Pie (9.0) Вы можете найти параметры разработчика в разделе «Настройки» > «Система» > «Параметры разработчика».

Что Google уже делает, чтобы убедиться, что Ваш телефон защищен

Ответственность за безопасность Вашего телефона так же лежит и на Google и он делает некоторые вещи, чтобы убедиться, что система безопасна.

Google Play Protect

Начиная с Android 8.0 (Oreo), Google выпустила функцию Play Protect. Это постоянно действующая, всегда проверяющая облачная система безопасности, которая следит за приложениями в Play Маркете и на Вашем устройстве. Она направлен на то, чтобы блокировать вредоносные приложения, в том числе поддельные приложения, и даже сканировать приложения, которые Вы загружаете.

Чтобы увидеть настройки Play Protect, откройте «Настройки» > «Google» > «Безопасность» > «Google Play Защита». Вы можете убедиться, что он включен (и он должен быть включен), а также включить сканирование приложений для загруженных приложений.

Шифрование на устройстве

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

Это означает, что все конфиденциальные данные на Вашем телефоне хранятся в не читаемом состоянии и не дешифруются до тех пор, пока Вы не введете пароль, PIN-код или код доступа.

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